-
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
Rollup of 5 pull requests #132762
Rollup of 5 pull requests #132762
Conversation
We only need to take action when the next block cannot be added to the current chain, but the logic is much simpler if we express it in terms of when the block _can_ be added.
The channel's `Block::new` was causing a stack overflow because it held 32 item slots, instantiated on the stack before moving to `Box::new`. The 32x multiplier made modestly-large item sizes untenable. That block is now initialized directly on the heap. Fixes rust-lang#102246
Improve identation, and a few other rvalue printing
…er-errors [StableMIR] A few fixes to pretty printing Improve identation, and a few other rvalue printing try-job: x86_64-msvc try-job: test-various
coverage: Simplify parts of coverage graph creation This is a combination of three semi-related simplifications to how coverage graphs are created, grouped into one PR to avoid conflicts. There are no observable changes to the output of any of the coverage tests.
…ouxu coverage: Extract safe FFI wrapper functions to `llvm_cov` This PR takes all of the inline `unsafe` calls in coverage codegen, and all the safe wrapper functions in `coverageinfo/mod.rs`, and moves them to a new `llvm_cov` submodule that is dedicated to safe FFI wrapper functions. This reduces the mixing of abstraction levels in the rest of coverage codegen. As a follow-up, this PR also tidies up the names and signatures of several of the coverage FFI functions.
Simplify FFI calls for `-Ztime-llvm-passes` and `-Zprint-codegen-stats` The existing code for these unstable LLVM-infodump flags was jumping through hoops to pass an allocated C string across the FFI boundary, when it's much simpler to just write to a `&RustString` instead.
…eemdev Initialize channel `Block`s directly on the heap The channel's `Block::new` was causing a stack overflow because it held 32 item slots, instantiated on the stack before moving to `Box::new`. The 32x multiplier made modestly-large item sizes untenable. That block is now initialized directly on the heap. Fixes rust-lang#102246 try-job: test-various
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 78bb5ee79e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (6295686): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.4%)This 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (primary 0.1%)This 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.
Bootstrap: 780.076s -> 781.673s (0.20%) |
Successful merges:
llvm_cov
#132452 (coverage: Extract safe FFI wrapper functions tollvm_cov
)-Ztime-llvm-passes
and-Zprint-codegen-stats
#132590 (Simplify FFI calls for-Ztime-llvm-passes
and-Zprint-codegen-stats
)Block
s directly on the heap #132738 (Initialize channelBlock
s directly on the heap)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup