-
Notifications
You must be signed in to change notification settings - Fork 18.3k
Description
cmd/compile only reports panics if it hasn't reported any errors, because it assumes panics are probably related to inconsistent state due to those previous errors. This is helpful for end users, but I think it ends up being confusing for errorcheck tests. If you make a change to cmd/compile that causes it to panic, but only after errors have been reported, then often errorcheck tests will start failing due to missing error messages. You have to know to try re-compiling the file manually with -d=panic
to see where the panic was and why those error messages went missing.
It would be nice if test/run.go automated this: If an errorcheck test fails because it's missing some errors, then re-run with -d=panic
so we can show the stack trace (if any).
The re-run is only necessary if cmd/compile already printed some errors (otherwise the panic should have already been included in the output), and that cmd/compile didn't already print any other unmatched errors (as unmatched errors are a separate issue unrelated to silent panics).
For example, https://storage.googleapis.com/go-build-log/c95e4698/linux-amd64_7e42686b.log has a failed errorcheck test that could plausible be from a silent panic. I suspect this one actually isn't, but it would be nice if test/run.go made it obvious whether or not that was the case.
/cc @cuonglm