Rollup of 4 pull requests #150190
Merged
Rollup of 4 pull requests #150190
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
... in `update_target_reliable_float_cfg`, based on the actual changes. The AArch64 issue is fixed on LLVM 20.1.1 while the MIPS issue is fixed on LLVM 20.1.0 (the first LLVM 20 release). This commit distinguishes two separate cases.
This commit simplifies floating type handling through
`update_target_reliable_float_cfg` based on several facts:
1. Major changes in behavior normally occurs only
on the major LLVM upgrade.
2. The first release of LLVM 20.x.x is 20.1.0.
Due to the first fact, we can normally ignore minor and patch releases
of LLVM and we can remove obscure variables like `lt_xx_x_x` (still,
there is a case where checking for patch version is required).
The second fact is missed when the minimum LLVM version is raised to
LLVM 20 and one "fixed in LLVM 20" case can be safely removed.
…cfg` This commit reorders certain match clauses in `update_target_reliable_float_cfg` by the architecture when there's no problems reordering it.
…dying, r=petrochenkov rustc_codegen_llvm: Tidying of `update_target_reliable_float_cfg` This PR simplifies floating type handling through `update_target_reliable_float_cfg` based on several facts: 1. Major changes in behavior normally occurs only on the major LLVM upgrade. 2. The first release of LLVM 20.x.x is 20.1.0. Due to the first fact, we can normally ignore minor and patch releases of LLVM and we can remove obscure variables like `lt_xx_x_x`. The second fact is missed when the minimum LLVM version is raised to LLVM 20 (cf. rust-lang#145071) and one "fixed in LLVM 20" case can be safely removed (another cannot be removed since it's fixed on LLVM 20.1.1). It also reorders certain `match` clauses by the architecture when there's no problems reordering it. Note that, an LLVM issue on MIPS is fixed on LLVM 20.1.**0** and another on AArch64 is fixed on LLVM 20.1.**1**. Originally, they are both considered fixed on LLVM 20.1.**1** but the author separated them into two cases (so that the MIPS bug checking can be removed).
…lbc, r=madsmtm Nvptx: Use llbc as default linker The implementation of [MCP: Use `llvm-bitcode-linker` as the default linker for `nvptx64-nvidia-cuda`](rust-lang/compiler-team#927)
miri genmc: fix exit() handling In genmc mode, Miri does not want to stop execution when `exit` is called. Instead we want to continue running other threads to ensure we covered all possible concurrent behaviors (including the ones where the exiting thread was delayed so the other threads took their turns first). However, the core interpreter has a sanity check that prevents us from just doing nothing in `exit`. This leaves us in a pickle: there's nowhere we can jump to (exit has return type `!` so there's no next block), but if we don't jump anywhere we ICE. The first commit fixes that by disabling the sanity check when there is no block to jump to. That still catches the mistake of forgetting to jump for the vast majority of shims. We currently don't build Miri's genmc integration in rustc CI so I had to hack the feature into the bootstrap miri integration. That turned out to use the wrong Miri binary, which is fixed by the second commit: we can just rely on CARGO_BIN_EXE_miri, there's no need for a MIRI environment variable. r? ``@oli-obk``
…aumeGomez Handle remapped paths correctly when generating "Source" links Fixes rust-lang#150100. This PR fixes a regression introduced by [rust-lang#149709](rust-lang#149709), I was overzealous in my changes (https://github.com/rust-lang/rust/pull/149709/changes#diff-e1cf7ef2fb411d24980cd4cbea1e867cc36029e9496e1ceca64cfb6a0e3510f6) and accidentally changed the behavior of `rustdoc` in the presence of remapped, to simply reject them instead of handling them. With this PR remapped paths are handled correctly, in a similar way as it was before. ~~I added a run-make test to make sure we don't regress it again, a simple `rustdoc` test in not sufficient as `rustdoc` is not called on the auxiliary crate. It's not pretty but it works.~~ rust-lang#150172 (comment) rustdoc doesn't have any handling for `--remap-path-scope`, so I used the `MACRO` scope (it was already used [elsewhere](https://github.com/rust-lang/rust/blob/b889870082dd0b0e3594bbfbebb4545d54710829/src/librustdoc/clean/types.rs#L154). cf. https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/source.20links.20missing.20for.20nightly.20std.20docs
rustbot
added
A-LLVM
Member
Author
|
@bors r+ rollup=never p=5 |
Collaborator
bors
added
S-waiting-on-bors
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: d0835adc4e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
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 d0835ad (parent) -> b53da99 (this PR) Test differencesShow 4 test diffsStage 1
Stage 2
Additionally, 2 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 b53da9908134f77da3bb36e7009ac81f02ee48dc --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 |
Collaborator
|
Finished benchmarking commit (b53da99): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@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 2.6%, secondary -1.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.2%, secondary 2.6%)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: 478.448s -> 479.876s (0.30%) |
Member
|
Regressions in doc benchmarks, so surely from the #150172 bug fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
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:
update_target_reliable_float_cfg#146747 (rustc_codegen_llvm: Tidying ofupdate_target_reliable_float_cfg)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup