-
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 7 pull requests #133609
Closed
Closed
Rollup of 7 pull requests #133609
Conversation
This file contains 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
Commands that end up invoking cc-rs, i.e. Cargo (through build scripts) and cmake-rs don't need the CFLAGS from cc-rs itself, as they will just end up as duplicates.
This didn't actually activate properly, since cmake-rs calls cc-rs internally, and as such the flag was set anyhow.
This commit adds the relevant registers to the list of clobbered regis- ters (part of rust-lang#93335). This follows the [ABI documentation] of AVR-GCC: > The [...] call-clobbered general purpose registers (GPRs) are > registers that might be destroyed (clobbered) by a function call. > > - **R18–R27, R30, R31** > > These GPRs are call clobbered. An ordinary function may use them > without restoring the contents. [...] > > - **R0, T-Flag** > > The temporary register and the T-flag in SREG are also call- > clobbered, but this knowledge is not exposed explicitly to the > compiler (R0 is a fixed register). Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM. Since the SREG is normally considered clobbered anyways (unless the user supplies the `preserve_flags`-option), there is no need to explicitly list a bit in this register (which is not possible to list anyways). Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways. [ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
Those are reserved as per the GCC (and thus LLVM) ABI, which is distinct from an issue. The rewording was requested in this [review]. [review]: rust-lang#131323 (comment)
I was surprised to find that running with `-Zparse-only` only parses the crate root file. Other files aren't parsed because that happens later during expansion. This commit renames the option and updates the help message to make this clearer.
To clarify how it works.
Previous setup instructions did not work without. (i.e. the envrc would not do anything, `nix flake show..` would provide unhelpful error)
this does two things: 1. allows making `build` a symlink (which is not considered a directory by git, thus removal of trailing `/`). 2. removes the need to special case `rustc_mir_build/src/build` (leading `/` makes git only ignore the `build` in the root)
this is funny though! apparently tidy parsed `.gitignore`, but did not recognize unignore lines (`!...`), so tidy was ignoring `rustc_mir_build` this whole time (at least for some lints?).
This reverts commit adf9b5f, reversing changes made to af1ca15. Reverting due to <rust-lang#133606>.
…i, r=Amanieu Support `clobber_abi` in AVR inline assembly This PR implements the `clobber_abi` part necessary to eventually stabilize the inline assembly for AVR. This is tracked in rust-lang#93335. This is heavily inspired by the sibling-PR rust-lang#131310 for the MSP430. I've explained my reasoning in the first commit message in detail, which is reproduced below for easier reviewing: This follows the [ABI documentation] of AVR-GCC: > The [...] call-clobbered general purpose registers (GPRs) are registers that might be destroyed (clobbered) by a function call. > > - **R18–R27, R30, R31** > > These GPRs are call clobbered. An ordinary function may use them without restoring the contents. [...] > > - **R0, T-Flag** > > The temporary register and the T-flag in SREG are also call-clobbered, but this knowledge is not exposed explicitly to the compiler (R0 is a fixed register). Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM. Since the SREG is normally considered clobbered anyways (unless the user supplies the `preserve_flags`-option), there is no need to explicitly list a bit in this register (which is not possible to list anyways). Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways. [ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers r? `@Amanieu` `@rustbot` label +O-AVR
…t, r=Mark-Simulacrum Always set the deployment target when building std `cc` has [a bug/feature](rust-lang/cc-rs#1171) (I guess depending on how you look at it) where the default deployment target is taken from the SDK instead of from `rustc`. This causes `compiler-builtins` to build `compiler-rt` with the wrong deployment target on iOS. I've been meaning to change how `cc` works in this regard, but that's a lengthy process, so let's fix it in bootstrap for now. The behaviour be seen locally with `./x build library --set build.optimized-compiler-builtins=true` for various target triples, and then inspecting with `otool -l build/host/stage1/lib/rustlib/*/lib/libcompiler_builtins-*.rlib | rg 'minos|version'`. I have added a rmake test that ensures that we now have the same version everywhere. Fixes rust-lang#128419 Fixes rust-lang/compiler-builtins#650 See also rust-lang/cargo#13115 `@rustbot` label O-apple
…acrum Don't use a SyntheticProvider for literally every type Replaces a glob regex with individualized imports for each standard library type. This improves debugger performance by quite a bit when populating lots of values with lots of fields With the glob, afaik every single value of every single type that the debugger renders is run through a python function that does quite a few string comparisons (i plan to fix those next) to determine the SyntheticProvider to use. It looks like DefaultSyntheticProvider's functions internally call the liblldb c++ functions, which ends up with identical behavior to not using a SyntheticProvider at all, except you have extra python round trips slowing things down. These sample vidoes were run on x86-64-pc-windows-gnu. `vect` is a 1000 element `Vec<Big>`, `Big` contains a dozen or so `Small`, and `Small` contains a dozen or so `[i32; 5]` Before: https://github.com/user-attachments/assets/07c31fe7-e126-4c2e-8ae9-cfe36e351d3f After: https://github.com/user-attachments/assets/6c0d1a45-1ffe-46de-95a0-5dbe59a173b5
…iler-errors Better diagnostic for fn items in variadic functions closes rust-lang#69232
…stebank Rename `-Zparse-only` It's a misleading name. r? ``@estebank``
Misc: better instructions for envrc, ignore `/build` instead of `build/` See commits for more information. r? `@jieyouxu`
Revert rust-lang#133418 (Store coverage source regions as `Span`) due to regression rust-lang#133606 This reverts commit adf9b5f, reversing changes made to af1ca15. Reverting rust-lang#133418 due to regressions reported at rust-lang#133606. r? jieyouxu
rustbot
added
A-run-make
Area: port run-make Makefiles to rmake.rs
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
Nov 29, 2024
@bors r+ rollup=never p=7 |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Nov 29, 2024
I would like the revert in #133608 to land before the next nightly, but to be polite to the rest of the queue I've included it in this rollup first. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 29, 2024
Rollup of 7 pull requests Successful merges: - rust-lang#131323 (Support `clobber_abi` in AVR inline assembly) - rust-lang#133092 (Always set the deployment target when building std) - rust-lang#133134 (Don't use a SyntheticProvider for literally every type) - rust-lang#133538 (Better diagnostic for fn items in variadic functions) - rust-lang#133590 (Rename `-Zparse-only`) - rust-lang#133592 (Misc: better instructions for envrc, ignore `/build` instead of `build/`) - rust-lang#133608 (Revert rust-lang#133418 (Store coverage source regions as `Span`) due to regression rust-lang#133606) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Nov 29, 2024
Can't tell if genuine, retrying |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Nov 29, 2024
@bors r- (the revert is being tested atm) |
bors
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Nov 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-run-make
Area: port run-make Makefiles to rmake.rs
rollup
A PR which is a rollup
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
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:
clobber_abi
in AVR inline assembly #131323 (Supportclobber_abi
in AVR inline assembly)-Zparse-only
#133590 (Rename-Zparse-only
)/build
instead ofbuild/
#133592 (Misc: better instructions for envrc, ignore/build
instead ofbuild/
)Span
) due to regression #133606 #133608 (Revert coverage: Store coverage source regions asSpan
until codegen #133418 (Store coverage source regions asSpan
) due to regression Regression in 2024-11-28: llvm-cov export errors with "truncated coverage data" #133606)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup