-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
rustc: Start moving toward "try_get is a bug" for incremental #44071
Conversation
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
d2a5977
to
b704502
Compare
@bors r+ |
📌 Commit b704502 has been approved by |
Hadn't considered this, very nice solution! As for everything else, I'm fine with non-user regressions. |
src/librustc/ty/maps.rs
Outdated
@@ -205,7 +206,9 @@ pub struct CycleError<'a, 'tcx: 'a> { | |||
} | |||
|
|||
impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> { | |||
pub fn report_cycle(self, CycleError { span, cycle }: CycleError) { | |||
pub fn report_cycle(self, CycleError { span, cycle }: CycleError) |
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.
Wait, can this and CycleError
be private? The only reason they're public is for try_get
, I think?
Also, CycleError
can probably be decomposed into its fields now? Not sure though.
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.
Sure yeah, I'll try to do this.
@bors: r=nikomatsakis |
📌 Commit b26eb6c has been approved by |
☔ The latest upstream changes (presumably #44046) made this pull request unmergeable. Please resolve the merge conflicts. |
This adds a function to `DiagnosticBuilder` to delay the entire diagnostic as a bug to be emitted at a later time. This'll end up getting used in the compiler in the subsequent commits...
This alters the return value of the `try_get` function so the error contains a diagnostic rather than a `CycleError`. This way consumers are forced to take *some* action (else they get a bug to an un-emitted diagnostic). This action could be to emit the error itself, or in some cases delay the diagnostic as a bug and continue.
The `sized_constraint` and `needs_drop_raw` queries both use `try_get` to detect cycles, but in both of these cases the cycle indicates an error has happened elsewhere in compilation. In these cases we can just delay the diagnostic to get emitted as a bug later if we ended up forgetting to emit the error diagnostic.
It sounds like this is being handled elsewhere, so for now just preserve the existing behavior of ignoring th error.
This seems like it may be likely to cause bugs with `RUST_LOG` and other "interesting" scenarios, but it removes the usage of `try_get` for now!
b26eb6c
to
11b9170
Compare
@bors: r=nikomatsakis |
📌 Commit 11b9170 has been approved by |
@bors r-
|
11b9170
to
c766aa4
Compare
@bors: r=nikomatsakis |
📌 Commit c766aa4 has been approved by |
rustc: Start moving toward "try_get is a bug" for incremental This PR is an effort to burn down some of the work items on #42633. The basic change here was to leave the `try_get` function exposed but have it return a `DiagnosticBuilder` instead of a `CycleError`. This means that it should be a compiler bug to *not* handle the error as dropping a diagnostic should result in a complier panic. After that change it was then necessary to update the compiler's callsites of `try_get` to handle the error coming out. These were handled as: * The `sized_constraint` and `needs_drop_raw` checks take the diagnostic and defer it as a compiler bug. This was a new piece of functionality added to the error handling infrastructure, and the idea is that for both these checks a "real" compiler error should be emitted elsewhere, so it's only a bug if we don't actually emit the complier error elsewhere. * MIR inlining was updated to just ignore the diagnostic. This is being tracked by #43542 which sounded like it either already had some work underway or was planning to change regardless. * The final case, `item_path`, is still sort of up for debate. At the time of this writing this PR simply removes the invocations of `try_get` there, assuming that the query will always succeed. This turns out to be true for the test suite anyway! It sounds like, though, that this logic was intended to assist in "weird" situations like `RUST_LOG` where debug implementations can trigger at any time. This PR would therefore, however, break those implementations. I'm unfortunately sort of out of ideas on how to handle `item_path`, but other thoughts would be welcome! Closes #42633
☀️ Test successful - status-appveyor, status-travis |
This PR is an effort to burn down some of the work items on #42633. The basic change here was to leave the
try_get
function exposed but have it return aDiagnosticBuilder
instead of aCycleError
. This means that it should be a compiler bug to not handle the error as dropping a diagnostic should result in a complier panic.After that change it was then necessary to update the compiler's callsites of
try_get
to handle the error coming out. These were handled as:sized_constraint
andneeds_drop_raw
checks take the diagnostic and defer it as a compiler bug. This was a new piece of functionality added to the error handling infrastructure, and the idea is that for both these checks a "real" compiler error should be emitted elsewhere, so it's only a bug if we don't actually emit the complier error elsewhere.item_path
, is still sort of up for debate. At the time of this writing this PR simply removes the invocations oftry_get
there, assuming that the query will always succeed. This turns out to be true for the test suite anyway! It sounds like, though, that this logic was intended to assist in "weird" situations likeRUST_LOG
where debug implementations can trigger at any time. This PR would therefore, however, break those implementations.I'm unfortunately sort of out of ideas on how to handle
item_path
, but other thoughts would be welcome!Closes #42633