Rollup of 9 pull requests #144360
Merged
Rollup of 9 pull requests #144360
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On the 32-bit win7 target, we use OS TLS instead of native TLS, due to issues with how the OS handles alignment. Unfortunately, this caused issues due to the TLS destructors not running, causing memory leaks among other problems. On Windows, to support OS TLS, the TlsAlloc family of function is used by Rust. This function does not support TLS destructors at all. However, rust has some code to emulate those destructors, by leveraging the TLS support functionality found in the MSVC CRT (specifically, in tlssup.c of the CRT). Specifically, the CRT provides the ability to register callbacks that are called (among other things) on thread destruction. By registering our own callback, we can run through a list of registered destructors functions to execute. To use this functionality, the user must do two things: 1. They must put the address to their callback in a section between `.CRT$XLB` and `.CRT$XLY`. 2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to make sure the TLS support code in tlssup.c isn't garbage collected by the linker. Prior to this commit, this second bit wasn't being done properly by the Rust TLS support code. Instead of adding a reference to _tls_used, it instead had a reference to its own callback to prevent it from getting GC'd by the linker. While this is _also_ necessary, not having a reference on _tls_used made the entire support non-functional. This commit reworks the code to: 1. Add an unconditional `#[used]` attribute on the CALLBACK, which should be enough to prevent it from getting GC'd by the linker. 2. Add a reference to `_tls_used`, which should pull the TLS support code into the Rust programs and not let it be GC'd by the linker.
Rather than adding `get_unused_rule` to the `TTMacroExpander` trait, put it on the concrete `MacroRulesMacroExpander`, and downcast to that type via `Any` in order to call it. Suggested-by: Vadim Petrochenkov <[email protected]>
This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations.
1. Rename `make_unclosed_delims_error` and return `Vec<Diag>` 2. change magic number `unclosed_delimiter_show_limit` to const 3. move `eof_err` below parsing logic 4. Add `calculate_spacing` for `bump` and `bump_minimal` Signed-off-by: xizheyin <[email protected]>
I missed this in the promotion to tier 2 with host tools. Signed-off-by: Jens Reidel <[email protected]>
this ensures that js-related tests can still be run from within such a dist tarball.
Remove tidy checks for `tests/ui/issues/` r? ``````````@jieyouxu`````````` As it is making cleanup efforts more difficult. This change was discussed here [#t-compiler > Discussion for ui test suite improvements @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Discussion.20for.20ui.20test.20suite.20improvements/near/529566433)
…isDenton Fix broken TLS destructors on 32-bit win7 Fixes rust-lang#141300 On the 32-bit win7 target, we use OS TLS instead of native TLS, due to issues with how the OS handles alignment. Unfortunately, this caused issues due to the TLS destructors not running, causing memory leaks among other problems. On Windows, to support OS TLS, the TlsAlloc family of function is used by Rust. This function does not support TLS destructors at all. However, rust has some code to emulate those destructors, by leveraging the TLS support functionality found in the MSVC CRT (specifically, in tlssup.c of the CRT). To use this functionality, the user must do two things: 1. They must put the address to their callback in a section between `.CRT$XLB` and `.CRT$XLY`. 2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to make sure the TLS support code in tlssup.c isn't garbage collected by the linker. Prior to this commit, this second bit wasn't being done properly by the Rust TLS support code. Instead of adding a reference to _tls_used, it instead had a reference to its own callback to prevent it from getting GC'd by the linker. While this is _also_ necessary, not having a reference on _tls_used made the entire support non-functional. This commit reworks the code to: 1. Add an unconditional `#[used]` attribute on the CALLBACK, which should be enough to prevent it from getting GC'd by the linker. 2. Add a reference to `_tls_used`, which should pull the TLS support code into the Rust programs and not let it be GC'd by the linker.
Clean `rustc/parse/src/lexer` to improve maintainability This PR refactors the lexer code to improve maintainability and eliminate code duplication. In the first commit, I improve the error handling: - rename `make_unclosed_delims_error` to more appropriate `make_mismatched_closing_delims_errors` - changes return type from Option<Diag> to `Vec<Diag>` to avoid lengthy vec processing at `lex_token_trees` - use `splice` instead of `extend` to make the logic clearer, since `errs` sounds more generic and better suited as a return value In the second commit, I replace the magic number 5 with UNCLOSED_DELIMITER_SHOW_LIMIT constant. In the third commit, I moves `eof_err` function below parsing logic for better code flow. In the forth one, I extract `calculate_spacing` function to eliminate duplicate spacing logic between `bump` and `bump_minimal` functions. r? compiler
Don't ICE on non-TypeId metadata within TypeId fixes rust-lang#144253 r? ``````````@RalfJung``````````
update tests/ui/SUMMARY.md follow-up of rust-lang#143985 . r? ```````@jieyouxu```````
…-for-get-unused-rule, r=petrochenkov mbe: Use concrete type for `get_unused_rule` Rather than adding `get_unused_rule` to the `TTMacroExpander` trait, put it on the concrete `MacroRulesMacroExpander`, and downcast to that type via `Any` in order to call it. Suggested-by: Vadim Petrochenkov <[email protected]> r? ```````@petrochenkov```````
coverage: Enlarge empty spans during MIR instrumentation, not codegen This re-lands the part of rust-lang#140847 that was (hopefully) not responsible for the coverage-instrumentation regressions that caused that PR to be reverted. --- Enlarging empty spans was historically performed during MIR instrumentation, but had to be moved to codegen as part of larger changes in rust-lang#134497, leading to the status quo. But now there should be no reason not to move that step back to its more logical home in instrumentaion.
…=Kobzol Add powerpc64le-unknown-linux-musl to CI rustc targets I missed this in the promotion to tier 2 with host tools.
…e.json, r=Kobzol bootstrap: add package.json and package-lock.json to dist tarball this ensures that js-related tests can still be run from within such a dist tarball. followup to rust-lang#142924 r? ```````@Kobzol```````
rustbot
added
A-LLVM
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 4ff3fa01cb In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 4ff3fa0 (parent) -> 29a5872 (this PR) Test differencesShow 6 test diffsStage 1
Stage 2
Additionally, 4 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 29a58723b05d004c2e19ddcf2be80d514401f22e --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 |
This was referenced Jul 23, 2025
|
Finished benchmarking commit (29a5872): 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)Results (secondary 1.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -2.4%)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: 468.179s -> 468.271s (0.02%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
tests/ui/issues/#144173 (Remove tidy checks fortests/ui/issues/)rustc/parse/src/lexerto improve maintainability #144239 (Cleanrustc/parse/src/lexerto improve maintainability)get_unused_rule#144292 (mbe: Use concrete type forget_unused_rule)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup