-
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
Shorten def_span for more items. #93967
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
Is Also, some rustdoc test has failed, not sure whether it's spurious or not. |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 3b96c413bb87321cadff009a710d71a5b32ae940 with merge dc992527fcd1dd0d3df63152c8875601eb5781b9... |
☀️ Try build successful - checks-actions |
Queued dc992527fcd1dd0d3df63152c8875601eb5781b9 with parent 902e590, future comparison URL. |
Finished benchmarking commit (dc992527fcd1dd0d3df63152c8875601eb5781b9): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
Yes. The
It looks like I need to reflect the change in line numbers in a doctest. The the link to source will only link to the struct head instead of the whole struct. (Like functions already do.) Last question: should we also do this for trait definitions? |
If we are doing this consistently, then the same span shortening is applicable to |
Hmm, I think it's fine, but just to be sure: @GuillaumeGomez can you check since you know this feature better? |
It doesn't seem to be a spurious failure. Something changed in the rendered output. |
Yeah, IIUC it went from highlighting these lines: struct Foo {
bar: i32
} to just the first: struct Foo { when you do a jump-to-def. |
3b96c41
to
686986f
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@46b8c23. Direct link to PR: <rust-lang/rust#93967> 💔 miri on windows: test-pass → test-fail (cc @RalfJung @oli-obk). 🎉 rls on linux: test-fail → test-pass (cc @Xanewok).
Finished benchmarking commit (46b8c23): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
…=estebank Shorten def_span of closures to just their header Continuation of rust-lang#93967.
Shorten def_span of closures to just their header Continuation of rust-lang/rust#93967.
Remove reachable coverage without counters to maintain invariant that either there is no coverage at all or there is a live coverage counter left that provides the function source hash. The motivating example would be a following closure: ```rust let f = |x: bool| { debug_assert!(x); }; ``` Which, with span changes from rust-lang#93967, with disabled debug assertions, after the final CFG simplifications but before removal of dead blocks, gives rise to MIR: ```rust fn main::{closure#0}(_1: &[[email protected]:2:13: 2:22], _2: bool) -> () { debug x => _2; let mut _0: (); bb0: { Coverage::Expression(4294967295) = 1 - 2; return; } ... } ```
Remove reachable coverage without counters Remove reachable coverage without counters to maintain invariant that either there is no coverage at all or there is a live coverage counter left that provides the function source hash. The motivating example would be a following closure: ```rust let f = |x: bool| { debug_assert!(x); }; ``` Which, with span changes from rust-lang#93967, with disabled debug assertions, after the final CFG simplifications but before removal of dead blocks, gives rise to MIR: ```rust fn main::{closure#0}(_1: &[[email protected]:2:13: 2:22], _2: bool) -> () { debug x => _2; let mut _0: (); bb0: { Coverage::Expression(4294967295) = 1 - 2; return; } ... } ``` Which also makes the initial instrumentation quite suspect, although this pull request doesn't attempt to address that aspect directly. Fixes rust-lang#98833. r? `@wesleywiser` `@richkadel`
Remove reachable coverage without counters Remove reachable coverage without counters to maintain invariant that either there is no coverage at all or there is a live coverage counter left that provides the function source hash. The motivating example would be a following closure: ```rust let f = |x: bool| { debug_assert!(x); }; ``` Which, with span changes from rust-lang#93967, with disabled debug assertions, after the final CFG simplifications but before removal of dead blocks, gives rise to MIR: ```rust fn main::{closure#0}(_1: &[[email protected]:2:13: 2:22], _2: bool) -> () { debug x => _2; let mut _0: (); bb0: { Coverage::Expression(4294967295) = 1 - 2; return; } ... } ``` Which also makes the initial instrumentation quite suspect, although this pull request doesn't attempt to address that aspect directly. Fixes rust-lang#98833. r? ``@wesleywiser`` ``@richkadel``
The
def_span
query only returns the signature span for functions.Struct/enum/union definitions can also have a very long body.
This PR shortens the associated span.