Rollup of 8 pull requests #142564
Closed
Rollup of 8 pull requests #142564
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
rustc_std_internal_symbol is meant to call functions from crates where there is no direct dependency on said crate. As they either have to be added to symbols.o or rustc has to introduce an implicit dependency on them to avoid linker errors. The latter is done for some things like the panic runtime, but adding these symbols to symbols.o allows removing those implicit dependencies.
This used to be necessary for a correct linker order, but ever since the introduction of symbols.o adding the symbols in question to symbols.o would work just as well. We do still add dependencies on the panic runtime to the local crate, but not for #![needs_panic_runtime] crates. This also removes the runtime-depends-on-needs-runtime test. inject_dependency_if used to emit this error, but with symbols.o it is no longer important that there is no dependency and in fact it may be nice to have panic_abort and panic_unwind directly depend on libstd in the future for calling std::process::abort().
You shouldn't ever need to explicitly depend on it. And we weren't checking that the panic runtime used the correct panic strategy either.
There is already panic-unwind to enable it.
In particular, anything that includes `none` in the target tripple, and `nvptx64-nvidia-cuda`
It wasn't really needed there.
It would not be correct if multiple values of `target_dir` were ever passed to the function in the same process.
Signed-off-by: xizheyin <[email protected]>
…sleywiser,ibraheemdev Reduce special casing for the panic runtime See the individual commits for more info.
…s, r=jdonszelmann Refactor `rustc_attr_data_structures` documentation I was reading through `AttributeKind` and realized that attributes like `InlineAttr` didn't appear in it, however, I found them in `rustc_codegen_ssa` and understood why (guessing). There's almost no overall documentation for this crate, I've added the organized documentation at the top of `lib.rs`, and I've grouped the Attributes into two categories: `AttributeKind` that run all through the compiler, and the ones that are only used in `codegen_ssa`, such as `InlineAttr`, `OptimizeAttr`, `InstructionSetAttr`. Also, I've added documentation for `AttributeKind` that further explains why attributes like `InlineAttr` don't appear in it, with examples for each variant. r? ``@jdonszelmann``
…enton Stabilize "file_lock" feature Closes rust-lang#130994 r? ``@joshtriplett``
…ss35 Fix Debug for Location Fixes rust-lang#142279
…ieyouxu ignore `run-make` tests that need `std` on targets without `std` In particular, anything that includes `none` in the target triple, and `nvptx64-nvidia-cuda`. Right now we don't cross-compile the `run-make` tests, but we want to in the future. This uses `//@ needs-target-std` introduced in rust-lang#142297. Useful for rust-lang#139244 and rust-lang#141856. The modified files are based on running rust-lang#141856 locally. It might be that rust-lang#139244 uncovers some additional files, but that PR needs to be rebased (though actually I'd advice to rebase the non-test changes onto this PR, probably faster that way). r? `@jieyouxu` <details> <summary>vim notes for future me</summary> Make a file with lines like this ``` /home/folkertdev/rust/rust/tests/run-make/export/disambiguator/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/invalid-so/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/no-builtins-attribute/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/export/extern-opt/rmake.rs:1:1 /home/folkertdev/rust/rust/tests/run-make/link-dedup/rmake.rs:1:1 ``` then ``` :set errorformat=%f:%l:%c :cfile /tmp/files-to-fix.txt ``` ``` :copen :cnext :cprev ``` are your friends </details>
…ouxu Assorted bootstrap cleanups (step 2) Very small improvements designed towards making bootstrap tests less hacky/special, and towards making it possible to run bootstrap tests in parallel. Best reviewed commit by commit. r? `@jieyouxu`
…=jieyouxu Add initial version of snapshot tests to bootstrap When making any changes to bootstrap (steps), it is very difficult to realize how does it affect various common bootstrap commands, and if everything still works as we expect it to. We are far away from having actual end-to-end tests, but what we could at least do is have a way of testing what steps does bootstrap execute in dry run mode. Now, we already have something like this in `src/bootstrap/src/core/builder/tests.rs`, however that is quite limited, because it only checks executed steps for a specific impl of `Step` and it does not consider step order. Recently, when working on what I thought was one of the simplest possible step untanglings in bootstrap (rust-lang#142357), I ran into errors in tests that were quite hard to debug. Partly also because the current staging test diffs are multiline and use `Debug` output, so it's quite difficult for me to make sense of them. In this PR, I introduce `insta`, which allows writing snapshot tests in a very simple way. With it, I want to allow writing tests that will clearly show us what is going on during bootstrap execution, and then write golden tests for `build/check/test` stage `0/1/2` for compiler/std/tools etc., to make sure that we don't regress something, and also to help with [#t-infra/bootstrap > Proposal to cleanup stages and steps after the redesign](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Proposal.20to.20cleanup.20stages.20and.20steps.20after.20the.20redesign/with/523488806), to help avoid a situation where we would (again) have to make a flurry of staging changes because of unexpected consequences. In the snapshot tests, we currently render the build of rustc, std and LLVM. Currently I render the executed steps using downcasting, which is not super pretty, but it allows us to make the test rendering localized in one place, and it's IMO enough for now. I implemented only a single test using the new machinery. Maybe if you take a look at it, you will understand why 😆 Bootstrap currently does some peculiar things, such as running a stage 0 std step (even though stage 0 std no longer exists) and running the Rustc stage 0 -> 1 step twice, once with a single crates, once with all rustc crates. So I think that even with this single step, there will be a bunch of things to fix in the near future... The way we currently prepare the Config test fixtures is far from ideal, this is something I think `@Shourya742` could work on as a part of their GSoC project (remove as much command execution from Config construction as possible, actually run bootstrap on a temporary directory instead of running it on the rustc checkout, create a Builder-like API for creating the Config test fixtures). r? `@jieyouxu`
…v, r=RalfJung clarify `rustc_do_not_const_check` comment ~~Given that we have used this attribute for other reasons before it seems appropriate to make this a "usually".~~ Add function name as a pointer cc ``@rust-lang/wg-const-eval``
rustbot
added
A-attributes
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jun 16, 2025
Rollup of 8 pull requests Successful merges: - #140809 (Reduce special casing for the panic runtime) - #142082 (Refactor `rustc_attr_data_structures` documentation) - #142125 (Stabilize "file_lock" feature) - #142373 (Fix Debug for Location) - #142414 (ignore `run-make` tests that need `std` on targets without `std`) - #142416 (Assorted bootstrap cleanups (step 2)) - #142431 (Add initial version of snapshot tests to bootstrap) - #142528 (clarify `rustc_do_not_const_check` comment) 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
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:
rustc_attr_data_structuresdocumentation #142082 (Refactorrustc_attr_data_structuresdocumentation)run-maketests that needstdon targets withoutstd#142414 (ignorerun-maketests that needstdon targets withoutstd)rustc_do_not_const_checkcomment #142528 (clarifyrustc_do_not_const_checkcomment)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup