Use fine grained component-wise span tracking in use trees#153838
Use fine grained component-wise span tracking in use trees#153838rust-bors[bot] merged 2 commits intorust-lang:mainfrom
Conversation
|
The parser was modified, potentially altering the grammar of (stable) Rust cc @fmease Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
r? @davidtwco rustbot has assigned @davidtwco. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| | | ||
| LL - with_crate!{$crate input TokenItem} | ||
| LL + with_crate!{token_site_span::TokenItem as _ input TokenItem} | ||
| LL + with_crate!{token_site_span::TokenItem as _} |
There was a problem hiding this comment.
These suggestions are now even more broken than before, but considering it was broken before, I think we should just leave it
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Use fine grained component-wise span tracking in use trees
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (cefe872): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 0.4%, secondary -0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 11.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 481.409s -> 480.983s (-0.09%) |
| self.prefix.span.to(self.hi_span()) | ||
| } | ||
|
|
||
| pub fn hi_span(&self) -> Span { |
There was a problem hiding this comment.
Could you document what are the results of span() and hi_span(), and how they can be different?
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@bors r=davidtwco |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 033b925 (parent) -> 9004856 (this PR) Test differencesShow 7 test diffs7 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 900485642855f4729d926ecf24680a791f9293cf --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (9004856): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -1.7%, secondary 2.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 489.04s -> 489.506s (0.10%) |
|
The regressed benchmark has a lot of warnings that go through those code paths. It's somewhat expected that it's more expensive to generate a span for a lint, but these all only happen on the emission path |
Use fine grained component-wise span tracking in use trees This often produces nicer spans and even doesn't need a Span field anymore (not that I expect the unused field to affect any perf, but still neat).
This often produces nicer spans and even doesn't need a Span field anymore (not that I expect the unused field to affect any perf, but still neat).