Properly handle lint spans after MIR inlining #76931
Conversation
rust-highfive
added
the
S-waiting-on-review
|
cc @lcnr |
| fn visit_span(&mut self, span: &mut Span) { | ||
| *span = self.callsite_span.fresh_expansion(ExpnData { | ||
| def_site: self.body_span, | ||
| ..ExpnData::default(ExpnKind::Inlined, *span, self.tcx.sess.edition(), None) |
There was a problem hiding this comment.
Should the edition be the edition of span? We could be inlining something from another crate which has a different edition than our current one.
There was a problem hiding this comment.
I was wondering that, too, but I don't see how the edition is relevant from the MIR on anyway, all of that checking happens waay earlier. I can't extract the edition from the span, because it may not have any ExpnData, so I would have to find the crate of the Span and check its edition. Doing something like this from a Span is something I don't think we've done before
This comment has been minimized.
This comment has been minimized.
oli-obk
added
the
S-blocked
camelid
removed
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
oli-obk
added
S-waiting-on-author
oli-obk
force-pushed
the
const_prop_inline_lint_madness
branch
from
4998709 to
c8a866e
Compare
oli-obk
added
S-waiting-on-review
|
@bors r+ |
|
📌 Commit 888ef24 has been approved by |
bors
added
S-waiting-on-bors
| @@ -56,7 +56,7 @@ | |||
| StorageLive(_6); // scope 3 at $DIR/cycle.rs:14:10: 14:11 | |||
| - _6 = _1; // scope 3 at $DIR/cycle.rs:14:10: 14:11 | |||
| + _6 = _4; // scope 3 at $DIR/cycle.rs:14:10: 14:11 | |||
| _5 = const (); // scope 4 at $SRC_DIR/core/src/mem/mod.rs:LL:COL | |||
| _5 = const (); // scope 4 at $DIR/cycle.rs:14:5: 14:12 | |||
There was a problem hiding this comment.
Does this affect the generated debuginfo? LLVM inlining preserves the original source position instead of using the position of the inlined call. The MIR inliner should do the same.
There was a problem hiding this comment.
The debuginfo part was handled in #68965
This here just addresses spans for diagnostics. These spans do preserve the original and all intermediate source positions across any level of inlining. I should probably adjust mir dumps to also print all spans instead of just the final one.
…ess, r=wesleywiser Properly handle lint spans after MIR inlining The first commit shows what happens when we apply mir inlining and then cause lints on the inlined MIR. The second commit fixes that. r? `@wesleywiser`
|
☀️ Test successful - checks-actions |
The first commit shows what happens when we apply mir inlining and then cause lints on the inlined MIR.
The second commit fixes that.
r? @wesleywiser