-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 8 pull requests #109001
Rollup of 8 pull requests #109001
Conversation
The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order: - Template strings - Positional operands - Named operands - Explicit register operands - `clobber_abi` - `options` This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows: - Template strings must still come before all other operands. - Positional operands must still come before named and explicit register operands. - Named and explicit register operands can be freely mixed. - `options` and `clobber_abi` can appear in any position.
SymbolWrapper.cpp doesn't use std::optional or llvm::Optional, so this patch removes the extraneous include. Note that llvm/ADT/Optional.h has been deprecated upstream. This patch ensures that SymbolWrapper.cpp continues to compile even after the upcoming removal of Optional.h.
Relax ordering rules for `asm!` operands The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order: - Template strings - Positional operands - Named operands - Explicit register operands - `clobber_abi` - `options` This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows: - Template strings must still come before all other operands. - Positional operands must still come before named and explicit register operands. - Named and explicit register operands can be freely mixed. - `options` and `clobber_abi` can appear in any position after the template strings. r? ```````@joshtriplett```````
…tr, r=dtolnay Stabilize path_as_mut_os_str Closes rust-lang#105021 r? ```@dtolnay```
…, r=pietroalbini use problem matchers for tidy CI
Stabilize movbe target feature Almost all "old" x86 target features are stable. As far as I can tell, these are the last two unstable features in the `x86-64-v2` or `x86-64-v3` microarchitecture levels, so I'm not sure if it was an oversight or if they're still unstable for a reason (see rust-lang#106323 for `f16c`). Note that this only stabilizes the target features, and not the intrinsics. cc ```@Amanieu``` r? ```@rust-lang/lang```
Add `--no-undefined-version` link flag and fix associated breakage LLVM upstream sets `--no-undefined-version` by default in lld: https://reviews.llvm.org/D135402. Due to a bug in how version scripts are generated, this breaks the `dylib` output type for most crates. See rust-lang#105967 (comment) for details. This PR adds the flag to gcc flavor linkers in anticipation of this LLVM change rolling in, and patches `rustc` to not attempt to export `__rust_*` allocator symbols when they weren't generated. Fixes rust-lang#105967
Remove an extraneous include SymbolWrapper.cpp doesn't use std::optional or llvm::Optional, so this patch removes the extraneous include. Note that llvm/ADT/Optional.h has been deprecated upstream. This patch ensures that SymbolWrapper.cpp continues to compile even after the upcoming removal of Optional.h.
…strieb no more do while :<
Document tool lints Add brief doc comments for the internal tool lints so a summary can be seen without needing to open source code
@bors r+ rollup=never p=8 |
⌛ Testing commit 030ea05 with merge c7010ae16a03aee5062badb0aade616a93ad93c5... |
💔 Test failed - checks-actions |
@bors retry
|
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: e350fe4e60 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
📌 Perf builds for each rolled up PR: previous master: 19c53768af In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (e350fe4): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
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.
CyclesThis benchmark run did not return any relevant results for this metric. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#105798 (Relax ordering rules for `asm!` operands) - rust-lang#105962 (Stabilize path_as_mut_os_str) - rust-lang#106085 (use problem matchers for tidy CI) - rust-lang#107711 (Stabilize movbe target feature) - rust-lang#108017 (Add `--no-undefined-version` link flag and fix associated breakage) - rust-lang#108891 (Remove an extraneous include) - rust-lang#108902 (no more do while :<) - rust-lang#108912 (Document tool lints) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Successful merges:
asm!
operands #105798 (Relax ordering rules forasm!
operands)--no-undefined-version
link flag and fix associated breakage #108017 (Add--no-undefined-version
link flag and fix associated breakage)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup