-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Overhaul -Ztreat-err-as-bug
#119871
Overhaul -Ztreat-err-as-bug
#119871
Conversation
Let me explain in some detail. Consider this program with a single type error.
Compile it normally and you get this:
Ok, that's fine. Now compile it with
There is a type error, and the compiler panics afterwards. But the error is labelled as an ICE, there is no error code, the error message is different, and it is missing the "expected" markers. Huh? Now compile it with
The type error is back to the original: it's a normal error instead of an ICE, the error message matches, the error code is there, and the "expected" markers are there. And again it panics afterwards. This is the behaviour I would expect with The final line of the last example explains it: "aborting after 1 errors and 1 delayed bugs". The compiler has "delayed bugs": a kind of second-class diagnostic that only gets printed at the end if no other errors are printed. They're widely used but mostly invisible; you never see them unless there's a bug in the compiler. And yet, So now we can now understand the I think this behaviour is very confusing and not what anybody is likely to want in practice. This PR changes |
This is somewhat disappointing since it doesn't (afaict) give you the capability to intercept a delayed bug anymore. I may add a edit: see convo in #119872, as long as we can land that, I'm happy with this. |
This comment has been minimized.
This comment has been minimized.
40f206e
to
0bfd2f9
Compare
If I wait for #119872 to merge, then I can use |
…ed-bugs, r=oli-obk,nnethercote Give me a way to emit all the delayed bugs as errors (add `-Zeagerly-emit-delayed-bugs`) This is probably a *better* way to inspect all the delayed bugs in a program that what exists currently (and therefore makes it very easy to choose the right number `N` with `-Zemit-err-as-bug=N`, though I guess the naming is a bit ironic when you pair both of the flags together, but that feels like naming bikeshed more than anything). This pacifies my only concern with rust-lang#119871 (comment), because (afaict?) that PR doesn't allow you to intercept a delayed bug's stack trace anymore, which as someone who debugs the compiler a lot, is something that I can *promise* that I do. r? `@nnethercote` or `@oli-obk`
Rollup merge of rust-lang#119872 - compiler-errors:eagerly-emit-delayed-bugs, r=oli-obk,nnethercote Give me a way to emit all the delayed bugs as errors (add `-Zeagerly-emit-delayed-bugs`) This is probably a *better* way to inspect all the delayed bugs in a program that what exists currently (and therefore makes it very easy to choose the right number `N` with `-Zemit-err-as-bug=N`, though I guess the naming is a bit ironic when you pair both of the flags together, but that feels like naming bikeshed more than anything). This pacifies my only concern with rust-lang#119871 (comment), because (afaict?) that PR doesn't allow you to intercept a delayed bug's stack trace anymore, which as someone who debugs the compiler a lot, is something that I can *promise* that I do. r? `@nnethercote` or `@oli-obk`
☔ The latest upstream changes (presumably #119889) made this pull request unmergeable. Please resolve the merge conflicts. |
`-Ztreat-err-as-bug` treats normal errors and delayed bugs equally, which can lead to some really surprising results. This commit changes `-Ztreat-err-as-bug` so it ignores delayed bugs, unless they get promoted to proper bugs and are printed. This feels to me much simpler and more logical. And it simplifies the implementation: - The `-Ztreat-err-as-bug` check is removed from in `DiagCtxt::{delayed_bug,span_delayed_bug}`. - `treat_err_as_bug` doesn't need to count delayed bugs. - The `-Ztreat-err-as-bug` panic message is simpler, because it doesn't have to mention delayed bugs. Output of delayed bugs is now more consistent. They're always printed the same way. Previously when they triggered `-Ztreat-err-as-bug` they would be printed slightly differently, via `span_bug` in `span_delayed_bug` or `delayed_bug`. A minor behaviour change: the "no errors encountered even though `span_delayed_bug` issued" printed before delayed bugs is now a note rather than a bug. This is done so it doesn't get counted as an error that might trigger `-Ztreat-err-as-bug`, which would be silly. This means that if you use `-Ztreat-err-as-bug=1` and there are no normal errors but there are delayed bugs, the first delayed bug will be shown (and the panic will happen after it's printed). Also, I have added a second note saying "those delayed bugs will now be shown as internal compiler errors". I think this makes it clearer what is happening, because the whole concept of delayed bugs is non-obvious. There are some test changes. - equality-in-canonical-query.rs: Minor output changes, and the error count reduces by one because the "no errors encountered even though `span_delayed_bug` issued" message is no longer counted as an error. - rpit_tait_equality_in_canonical_query.rs: Ditto. - storage-live.rs: The query stack disappears because these delayed bugs are now printed at the end, rather than when they are created. - storage-return.rs, span_delayed_bug.rs: now need `-Zeagerly-emit-delayed-bugs` because they need the delayed bugs emitted immediately to preserve behaviour.
0bfd2f9
to
f1ac541
Compare
I updated and adjusted some of the test changes back by using the new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me when green
It's green. @bors r=compiler-errors |
☀️ Test successful - checks-actions |
Finished benchmarking commit (284cb71): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 668.237s -> 669.206s (0.15%) |
It's current behaviour is surprising, in a bad way. This also makes the implementation more complex than it needs to be.
r? @oli-obk