Make post-monomorphization error detection work with fatal errors#153194
Make post-monomorphization error detection work with fatal errors#153194Zoxc wants to merge 2 commits intorust-lang:mainfrom
Conversation
|
rustbot has assigned @JonathanBrouwer. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
@rustbot reroll |
|
@rustbot reroll |
|
@rustbot reroll |
There was a problem hiding this comment.
The main problem is that most of the additional error messages aren't useful. They just repeat the previous error. E.g. this error:
error: reached the recursion limit while instantiating `generic::<Option<Option<Option<Option<...>>>>>`
--> $DIR/infinite-function-recursion-error-8727.rs:9:5
is augmented with this note:
note: the above error was encountered while instantiating `fn generic::<Option<Option<Option<Option<...>>>>>`
--> $DIR/infinite-function-recursion-error-8727.rs:9:5
There are a couple of exceptions, but it's not clear to me that the potential benefit in those exception cases are outweighed by the duplication in the common cases.
| // | ||
| // FIXME: don't rely on global state, instead bubble up errors. Note: this is very hard to do. | ||
| // FIXME: This detection can have false positives with the parallel compiler. | ||
| // FIXME: The notes may not be right after the original error with the parallel compiler. |
There was a problem hiding this comment.
Are you documenting existing behaviours, or are these new behaviours?
This makes post-monomorphization error detection work with fatal errors by using
deferso it can catch fatal errors too.Found this while working on making cycle errors fatal.
cc @lqd @oli-obk