-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
Comments
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. |
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. |
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. |
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>
CL https://golang.org/cl/21347 mentions this issue. |
See discussion in #15029. Change-Id: I5cc8be5737ddb7c1f5e4a6cd92cf557af45e961d Reviewed-on: https://go-review.googlesource.com/21347 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
https://go-review.googlesource.com/#/c/21333/
When I try testing that CL, I get:
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
The text was updated successfully, but these errors were encountered: