-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Rollup of 12 pull requests #142574
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 12 pull requests #142574
Conversation
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]>
Signed-off-by: xizheyin <[email protected]>
They were using `--config` instead of `--set`, which overrides too much stuff.
Expose discriminant values in stable_mir Resolves rust-lang/project-stable-mir#93 * Added `Discr` struct to stable mir as stable version of struct with same name * Added `discriminant_for_variant` method to `AdtDef` and `CoroutineDef`
…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```
…cs, r=tgross35 Add documentation for `PathBuf`'s `FromIterator` and `Extend` impls I think it's not very obvious that `PathBuf`'s `Extend` and `FromIterator` impls work like `PathBuf::push`, so I think these should be documented. I'm not very happy with the wording and examples, open to suggestions :)
…ss35 Fix Debug for Location Fixes rust-lang#142279
…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``
…wLii Add documentation on top of `rustc_middle/src/query/mod.rs` The `rustc-dev-guide` gives a high-level intro, but many details—especially about how the code works and modifiers in `query xxx(){...}`—are only in code comments or the macro implementation. This doc makes it easier for contributors and code readers to understand the workflow and available modifiers without jumping between files and docs. This PR adds a comprehensive module-level doc comment to `rustc_middle::query::mod.rs` that: 1. Provides an overview of the query system and macro-based query definitions for reading code more easily 2. Centralizes documentation for all query modifiers (previously scattered or only in `rustc_macro` code), closely following the authoritative list in QueryModifiers.
…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```
…q, r=compiler-errors use `if let` guards where possible these crates already enable the feature
…nyukang Remove an `njn:` comment accidentaly left behind. r? `@chenyukang`
Fix `-nopt` CI jobs They were using `--config` instead of `--set`, which overrides too much stuff after recent changes to config merging. Should hopefully unblock rust-lang#142447. r? `@jieyouxu`
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
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 d9ca9bd (parent) -> 3bc767e (this PR) Test differencesShow 2639 test diffsStage 1
(and 965 additional test diffs) Additionally, 1574 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 3bc767e1a215c4bf8f099b32e84edb85780591b1 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
📌 Perf builds for each rolled up PR:
previous master: d9ca9bd014 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Rollup of 12 pull requests Successful merges: - rust-lang#141639 (Expose discriminant values in stable_mir) - rust-lang#142082 (Refactor `rustc_attr_data_structures` documentation) - rust-lang#142125 (Stabilize "file_lock" feature) - rust-lang#142236 (Add documentation for `PathBuf`'s `FromIterator` and `Extend` impls) - rust-lang#142373 (Fix Debug for Location) - rust-lang#142416 (Assorted bootstrap cleanups (step 2)) - rust-lang#142431 (Add initial version of snapshot tests to bootstrap) - rust-lang#142450 (Add documentation on top of `rustc_middle/src/query/mod.rs`) - rust-lang#142528 (clarify `rustc_do_not_const_check` comment) - rust-lang#142530 (use `if let` guards where possible) - rust-lang#142561 (Remove an `njn:` comment accidentaly left behind.) - rust-lang#142566 (Fix `-nopt` CI jobs) r? `@ghost` `@rustbot` modify labels: rollup
Finished benchmarking commit (3bc767e): comparison URL. Overall result: ❌ regressions - no action needed@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 -7.3%, secondary 10.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 756.489s -> 757.216s (0.10%) |
Successful merges:
rustc_attr_data_structures
documentation #142082 (Refactorrustc_attr_data_structures
documentation)PathBuf
'sFromIterator
andExtend
impls #142236 (Add documentation forPathBuf
'sFromIterator
andExtend
impls)rustc_middle/src/query/mod.rs
#142450 (Add documentation on top ofrustc_middle/src/query/mod.rs
)rustc_do_not_const_check
comment #142528 (clarifyrustc_do_not_const_check
comment)if let
guards where possible #142530 (useif let
guards where possible)njn:
comment accidentaly left behind. #142561 (Remove annjn:
comment accidentaly left behind.)-nopt
CI jobs #142566 (Fix-nopt
CI jobs)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup