-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 3 pull requests #118579
Rollup of 3 pull requests #118579
Conversation
When we extract coverage spans from MIR, we try to "un-expand" them back to spans that are inside the function's body span. In cases where that doesn't succeed, the current code just swaps in the entire body span instead. But that tends to result in coverage spans that are completely unrelated to the control flow of the affected code, so it's better to just discard those spans.
Instead of allowing `rustc::potential_query_instability` on the whole crate we go over each lint and allow it individually if it is safe to do. Turns out all instances were safe to allow in this crate.
…g-item-decl, r=notriddle [rustdoc] Add highlighting for comments in items declaration Fixes rust-lang#117555. So after the discussion in rust-lang#117643, the outcome was that having the comments in the item declaration at the same level (in term of color) as the rest of the code was actually a bit distracting and could be improved. The current highlighting color for comments is "lighter" than the rest and I think it fits perfectly to improve the current situation. With this, we now have different "levels" which makes it easier to read and filter out what we want when reading the items declaration. Here's a screenshot: ![image](https://github.com/rust-lang/rust/assets/3050060/dbd98029-e98b-4997-9a89-6b823eaac9a4) r? `@notriddle`
coverage: Skip spans that can't be un-expanded back to the function body When we extract coverage spans from MIR, we try to "un-expand" them back to spans that are inside the function's body span. In cases where that doesn't succeed, the current code just swaps in the entire body span instead. But that tends to result in coverage spans that are completely unrelated to the control flow of the affected code, so it's better to just discard those spans. --- Extracted from rust-lang#118305, since this is a general improvement that isn't specific to branch coverage. --- `@rustbot` label +A-code-coverage
rustc_session: Address all `rustc::potential_query_instability` lints Instead of allowing `rustc::potential_query_instability` on the whole crate we go over each lint and allow it individually if it is safe to do. Turns out all instances were safe to allow in this crate. Part of rust-lang#84447 which is **E-help-wanted**.
@bors r+ rollup=never p=3 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: d12dc74a2c In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (9fad685): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 673.016s -> 672.475s (-0.08%) |
Successful merges:
rustc::potential_query_instability
lints #118574 (rustc_session: Address allrustc::potential_query_instability
lints)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup