Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: spooky compilation failure #15029

Closed
mdempsky opened this issue Mar 30, 2016 · 4 comments
Closed

cmd/compile: spooky compilation failure #15029

mdempsky opened this issue Mar 30, 2016 · 4 comments

Comments

@mdempsky
Copy link
Contributor

https://go-review.googlesource.com/#/c/21333/

When I try testing that CL, I get:

$ go run run.go
# go run run.go -- fixedbugs/bug278.go

bug278.go:21: missing error "cannot|invalid"
bug278.go:22: missing error "cannot|invalid"

FAIL    fixedbugs/bug278.go 0.081s
# go run run.go -- fixedbugs/issue8183.go

issue8183.go:21: missing error "const initializer len\\(composite literal\\) is not a constant"
issue8183.go:22: missing error "array bound must be non-negative"
issue8183.go:22: missing error "const initializer len\\(composite literal\\) is not a constant"

FAIL    fixedbugs/issue8183.go  0.075s
exit status 1

I don't see how that's possible. Either the compiler should have panicked because at some point t == nil, or the behavior should have been identical.

/cc @randall77 @josharian

@josharian
Copy link
Contributor

Try Fatalf. Panics are caught and handled later, and my guess is that the typchecking error happens before the panic gets printed.

As an aside, it'd sure be nice for Fatalf to print the stack before dying.

@randall77
Copy link
Contributor

I too have been annoyed that when the compiler itself fails, you sometimes don't get a good report. The -h flag to the compiler sometimes helps. It would be a good thing to clean up / normalize.

Keep in mind though that we're not the target audience. Error reports need to be understandable and reportable by the average Go user.

@mdempsky
Copy link
Contributor Author

Ugh, yeah, the panic is just getting eaten somewhere. So at least that clarifies the "spookiness".

Agreed that error reports are targeting the end users. What was confusing me is that there wasn't any output due to the panic, so I thought it just wasn't triggering at all. Which made me extra confused why some of the error messages went missing.

sbinet pushed a commit to sbinet/golang-go that referenced this issue Mar 30, 2016
Replace Isfixedarray, Isslice, and Isinter with the IsArray, IsSlice,
and IsInterface methods added for SSA. Rewrite performed mechanically
using gofmt -w -r "Isfoo(t) -> t.IsFoo()".

Because the IsFoo methods panic when given a nil pointer, a handful of
call sites had to be modified to check for nil Type values. These
aren't strictly necessary, because nil Type values should only occur
in invalid Go source programs, so it would be okay if we panicked on
them and gave up type checking the rest of the package. However, there
are a couple regress tests that expect we continue, so add checks to
keep those tests passing. (See golang#15029.)

Passes toolstash -cmp.

Change-Id: I511c6ac4cfdf3f9cbdb3e52a5fa91b6d09d82f80
Reviewed-on: https://go-review.googlesource.com/21336
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@gopherbot
Copy link
Contributor

CL https://golang.org/cl/21347 mentions this issue.

gopherbot pushed a commit that referenced this issue Mar 31, 2016
See discussion in #15029.

Change-Id: I5cc8be5737ddb7c1f5e4a6cd92cf557af45e961d
Reviewed-on: https://go-review.googlesource.com/21347
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@golang golang locked and limited conversation to collaborators Mar 31, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants