-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Bad MIR spans #99854
Comments
This is trivially false in the face of macros and MIR function inlining, right? #[inline(always)]
fn inline_me() -> u32 {
42
}
pub fn root() -> u32 {
inline_me()
} when compiled with nightly and optimizations enabled gives the following MIR: fn root() -> u32 {
let mut _0: u32; // return place in scope 0 at src/lib.rs:6:18: 6:21
scope 1 (inlined inline_me) { // at src/lib.rs:7:5: 7:16
}
bb0: {
_0 = const 42_u32; // scope 1 at src/lib.rs:3:5: 3:7
return; // scope 0 at src/lib.rs:8:2: 8:2
}
}
|
Good point, I did not consider this. I guess then the assertion should not be added, and the spans from outside should be better dealt with (I am not sure how that would look like though). cc @oli-obk |
Yea, I think we should not use relative offsets unless the span is within the function's span. Basically fallback to just the original span in that case |
That sounds good, I'll improve that. |
There are still a few issues that should be improved: #99908 (comment) |
@rustbot label +A-mir |
In #99780 (comment), I tried to add an assertion in the span formatting function to validate that the span for the
mir::Body.span
span always contains all spans of MIR statements/terminators.But this assertion failed for many tests. One such case was for associated constants.
We should investigate all the cases where the MIR body span is not fully correct, and add the assertion back in.
The text was updated successfully, but these errors were encountered: