Automatic Rustup #3537
Merged
Automatic Rustup #3537
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Convert some iter macros to normal functions With all the MIR optimization changes that have happened since these were written, let's see if they still actually matter. \*perf comes back\* Well, it looks like it's not longer relevant for instruction, cycle, nor wall-time perf. Looks like a bunch of things are maybe 10kb bigger in debug, but some are also 50k *smaller* in debug. So I think they should switch to being normal functions as the "greatly improves performance" justification for them being macros seems to no longer be true -- probably thanks to us always building `core` with `-Z inline-mir` so the difference is negligible.
Add support for run-make-support unit tests to be run with bootstrap The `run-make-support` library needs to run its unit tests to ensure it is correct. Close #124267
…r-errors `obligations_for_self_ty`: use `ProofTreeVisitor` for nested goals As always, dealing with proof trees continues to be a hacked together mess. After this PR and #124380 the only remaining blocker for core is rust-lang/trait-system-refactor-initiative#90. There is also a `ProofTreeVisitor` issue causing an ICE when compiling `alloc` which I will handle in a separate PR. This issue likely affects coherence diagnostics more generally. The core idea is to extend the proof tree visitor to support visiting nested candidates without using a `probe`. We then simply recurse into nested candidates if they are the only potentially applicable candidate for a given goal and check whether the self type matches the expected one. For that to work, we need to improve `CanonicalState` to also handle unconstrained inference variables created inside of the trait solver. This is done by extending the `var_values` of `CanoncalState` with each fresh inference variables. Furthermore, we also store the state of all inference variables at the end of each probe. When recursing into `InspectCandidates` we then unify the values of all these states. r? `@compiler-errors`
Stabilize `Utf8Chunks` Pending FCP in rust-lang/rust#99543. This PR includes the proposed modification in rust-lang/libs-team#190 as agreed in rust-lang/rust#99543 (comment).
bootstrap: keep all cargo test files in dist rustc-src Cargo tests use some files that we would otherwise exclude, especially the `cargo init` tests that are meant to deal with pre-existing `.git` and `.hg` repos and their ignore files. Keeping these in our dist tarball doesn't take much space, and allows distro builds to run these tests successfully.
Miri subtree update r? `@ghost`
…ilstrieb Relax `A: Clone` bound for `rc::Weak::into_raw_and_alloc` Makes this method to behave the same way as [`Box::into_raw_with_allocator`](https://doc.rust-lang.org/1.77.2/alloc/boxed/struct.Box.html#method.into_raw_with_allocator) and [`Vec::into_raw_parts_with_alloc`](https://doc.rust-lang.org/1.77.2/alloc/vec/struct.Vec.html#method.into_raw_parts_with_alloc). I have also noticed the inconsistent presence and naming, should probably be addressed in the future.
miri core/alloc tests: do not test a 2nd target check-aux seems to be one of the slowest runners since we started running standard library tests in Miri on it. So maybe it'd be better to reduce test coverage a bit by not doing cross-target testing of core and alloc? I don't recall finding target-specific issues in these libraries ever (and we still have the extra test coverage via our [out-of-tree nightly tests](https://github.com/rust-lang/miri-test-libstd)). This gives us more buffer to deal with the fact that the number of tests we run will only grow over time. Cc `@rust-lang/miri` `@rust-lang/infra`
Bootstrap: Check validity of `--target` and `--host` triples before starting a build Resolves #122128 As described in the issue, validating the `target` and `host` triples would save a lot of time before actually starting a build. This would also check for custom targets by looking for a valid JSON spec if the specified target does not exist in the [supported](https://github.com/rust-lang/rust/blob/42825768b103c28b10ce0407749acb21d32abeec/compiler/rustc_target/src/spec/mod.rs#L1401-L1689) list of targets.
…ulacrum Abort a process when FD ownership is violated When an owned FD has already been closed before it's dropped that means something else touched an FD in ways it is not allowed to. At that point things can already be arbitrarily bad, e.g. clobbered mmaps. Recovery is not possible. All we can do is hasten the fire. Unlike the previous attempt in #124130 this shouldn't suffer from the possibility that FUSE filesystems can return arbitrary errors.
…ulacrum drop deprecated value `if-available` for `download-ci-llvm` option It's been 5 months since we deprecated this. It should be fine to drop its support now.
The functionality of all three crates is now available in the standard library.
…eril Fix the assertion crash from rustdoc document indent widths Fixes #124363
…lathar
MCDC coverage: support nested decision coverage
#123409 provided the initial MCDC coverage implementation.
As referenced in #124144, it does not currently support "nested" decisions, like the following example :
```rust
fn nested_if_in_condition(a: bool, b: bool, c: bool) {
if a && if b || c { true } else { false } {
say("yes");
} else {
say("no");
}
}
```
Note that there is an if-expression (`if b || c ...`) embedded inside a boolean expression in the decision of an outer if-expression.
This PR proposes a workaround for this cases, by introducing a Decision context stack, and by handing several `temporary condition bitmaps` instead of just one.
When instrumenting boolean expressions, if the current node is a leaf condition (i.e. not a `||`/`&&` logical operator nor a `!` not operator), we insert a new decision context, such that if there are more boolean expressions inside the condition, they are handled as separate expressions.
On the codegen LLVM side, we allocate as many `temp_cond_bitmap`s as necessary to handle the maximum encountered decision depth.
CI: remove `master` job It only had one job (pun intended), to publish the toolstate. We could probably do that at the end of `auto` builds instead, which is what is done in this PR. r? `@pietroalbini`
Pretty-print parenthesis around binary in postfix match Fixes #124206.
Remove direct dependencies on lazy_static, once_cell and byteorder
The relevant functionality of all three crates is now available and stable in the standard library, i.e. `std::sync::OnceLock` and `{integer}::to_le_bytes`. I think waiting for `LazyLock` (#109736) would give marginally more concise code, but not by much.
Fix #124478 - offset_of! returns a temporary This was due to the must_use() call. Adding HIR's `OffsetOf` to the must_use checking within the compiler avoids this issue while maintaining the lint output. Fixes #124478. `@tgross35`
Mark unions non-const-propagatable in `KnownPanicsLint` without calling layout Fixes #123710 The ICE occurs during the layout calculation of the union `InvalidTag` in #123710 because the following assert fails:https://github.com/rust-lang/rust/blob/5fe8b697e729b6eb64841a3905e57da1b47f4ca3/compiler/rustc_abi/src/layout.rs#L289-L292 The layout calculation is invoked by `KnownPanicsLint` when it is trying to figure out which locals it can const prop. Since `KnownPanicsLint` is never actually going to const props unions thanks to PR rust-lang/rust#121628 there's no point calling layout to check if it can. So in this fix I skip the call to layout and just mark the local non-const propagatable if it is a union.
coverage: Avoid hard-coded values when visiting logical ops This is a tiny little thing that I noticed during the final review of #123409, and I didn't want to hold up the whole PR just for this. Instead of separately hard-coding the operation being visited, we can get it from the match arm pattern by using an as-pattern. `@rustbot` label +A-code-coverage
[Refactor] Rename `Lint` and `LintGroup`'s `is_loaded` to `is_externally_loaded` The field being named `is_loaded` was very confusing. Turns out it's true for lints that are registered by external tools like Clippy (I had to look at rust-lang/rust#116412 to know what the variable meant). So I renamed `is_loaded` to `is_externally_loaded` and added some docs.
Rollup of 7 pull requests Successful merges: - #124269 (Pretty-print parenthesis around binary in postfix match) - #124415 (Use probes more aggressively in new solver) - #124475 (Remove direct dependencies on lazy_static, once_cell and byteorder) - #124484 (Fix #124478 - offset_of! returns a temporary) - #124504 (Mark unions non-const-propagatable in `KnownPanicsLint` without calling layout) - #124508 (coverage: Avoid hard-coded values when visiting logical ops) - #124522 ([Refactor] Rename `Lint` and `LintGroup`'s `is_loaded` to `is_externally_loaded` ) r? `@ghost` `@rustbot` modify labels: rollup
tests: remove some trailing ws Cleans one more case of trailing whitespace in tests.
coverage: Replace boolean options with a `CoverageLevel` enum After #123409, and some discussion at rust-lang/rust#79649 (comment) and #124120, it became clear to me that we should have a unified concept of “coverage level”, instead of having several separate boolean flags that aren't actually independent. This PR therefore introduces a `CoverageLevel` enum, to replace the existing boolean flags for `branch` and `mcdc`. The `no-branch` value (for `-Zcoverage-options`) has been renamed to `block`, instructing the compiler to only instrument for block coverage, with no branch coverage or MD/DC instrumentation. `@rustbot` label +A-code-coverage cc `@ZhuUx` `@Lambdaris` `@RenjiSann`
CI: remove `expand-yaml-anchors` This PR unifies all CI outcome jobs in a single job, and then removes the `expand-yaml-anchors` tool, since it is no longer needed after this change. I have tested try builds for both situations with the new `outcome` job (note that these two workflow runs use a different step structure in the outcome job, I have simplified it since): - [Success](https://github.com/rust-lang-ci/rust/actions/runs/8831529677/job/24251135366) - [Failure](https://github.com/rust-lang-ci/rust/actions/runs/8833052319/job/24251628792) r? `@ghost`
Lazily normalize inside trait ref during orphan check & consider ty params in rigid alias types to be uncovered Fixes #99554, fixes rust-lang/types-team#104. Fixes #114061. Supersedes #100555. Tracking issue for the future compatibility lint: #124559. r? lcnr
Use `target_vendor = "apple"` instead of `target_os = "..."` Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`. The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific. Note that `target_vendor` will [be deprecated in the future](rust-lang/rust#100343), but not before an alternative (like `target_family = "apple"`) is available. While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang/rust#124494 Since you've talked about using `target_vendor = "apple"` in the past: r? workingjubilee CC `@simlay,` `@thomcc` `@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
Consider inner modules to be local in the `non_local_definitions` lint This PR implements the [proposed fix](rust-lang/rust#124396 (comment)) for #124396, that is to consider inner modules to be local in the `non_local_definitions` lint. This PR is voluntarily kept as minimal as possible so it can be backported easily. T-lang [nomination](rust-lang/rust#124396 (comment)) will need to be removed before this can be merged. Fixes *(nearly, needs backport)* rust-lang/rust#124396
Normalize bootstrap_out path Fixes #112785
rustc: document the jobserver Explicitly document that the jobserver may be used by `rustc`, as well as recommend the `+` indicator for integration of `rustc` into GNU Make. In particular, show the warning to increase the chances that this document is found when searching for solutions online. In addition, add a note about the issue with GNU Make 4.3 since it is important that users realize they should do this even if they do not expect parallelism from `rustc`. Finally, show how to workaround the issue of `$(shell ...)` calls in recursive Make (which e.g. was needed for the Linux kernel). The GNU Make 4.4 case under `--jobserver-style=pipe` is not added since it got fixed after Rust 1.76.0 already (i.e. `rustc` will not warn if it finds the negative file descriptors). From: rust-lang/rust#120515 Cc: `@petrochenkov` `@belovdv` `@weihanglo` `@bjorn3` --- v2: To be able to use tab characters for the Make examples, add `<!-- ignore-tidy-{check} -->` support to `tidy`. v3: Added "Integration with build systems" section to hold the GNU Make one. Added "by clearing the `MAKEFLAGS` variable". Added "aforementioned" so that it is clear we are talking about the warning above. v4: Added CMake subsection. Added a note that `rustc` may be affected by other flags, e.g. `CARGO_MAKEFLAGS`. v5: Added that `rustc` will choose the number of jobs if a jobserver is not passed.
…isnc Arm bare-metal target doc changes Updates the Arm bare-metal target docs: * Detailed pages for all the Cortex-M targets, including details about setting target-cpu and target-features to suit specific Arm models * More detail about the difference between `eabi` and `eabihf` * Marks the Embedded Devices Working Group Cortex-M Team as the maintainer of the Cortex-M targets
…ingjubilee Document never type fallback in `!`'s docs Pulled the documentation I've written for #123939. I want a single place where never type fallback is explained, which can be referred in all the lints and migration materials.
…=davidtwco Ignore LLVM ABI in dlltool tests since those targets don't use dlltool Otherwise those two tests fail when running `./x.py test` with this target.
remove extraneous note on `UnableToRunDsymutil` diagnostic If I understand [this FIXME](https://github.com/rust-lang/rust/blob/1367827eac3d813a261a4c444037af9736996daa/compiler/rustc_macros/src/diagnostics/diagnostic.rs#L205) correctly, it seems we don't yet validate subdiagnostics, so `#[note]` and co in the `#[derive(Diagnostic]` item could be out-of-sync with the fluent message, without causing compile errors. It was the case for `rustc_codegen_ssa::errors::UnableToRunDsymutil`, causing the ICE in #124392. I've grepped and scripted my way through most of our diagnostics structs and fluent bundles and the above was the only such extraneous `#[note]`/`#[note(name)]`/`#[help]`/`#[warning]` I could find, so hopefully there aren't many others like it. I haven't checked if the opposite can happen, a `.note = ` in a fluent message that is lacking a corresponding `#[note]` on the struct and not causing an error, but maybe it's possible? r? ``@davidtwco`` fixes #124392
Use `tcx.types.unit` instead of `Ty::new_unit(tcx)` I don't think there is any need for the function, given that we can just access the `.types`, similarly to all other primitives?
interpret: hide some reexports in rustdoc Cc rust-lang/rust#124608
Rollup of 7 pull requests Successful merges: - #124138 (Ignore LLVM ABI in dlltool tests since those targets don't use dlltool) - #124414 (remove extraneous note on `UnableToRunDsymutil` diagnostic) - #124579 (Align: add bytes_usize and bits_usize) - #124622 (Cleanup: Rid the `rmake` test runners of `extern crate run_make_support;`) - #124623 (shallow resolve in orphan check) - #124624 (Use `tcx.types.unit` instead of `Ty::new_unit(tcx)`) - #124627 (interpret: hide some reexports in rustdoc) r? `@ghost` `@rustbot` modify labels: rollup
|
@bors r+ |
|
💔 Test failed - checks-actions |
|
@bors r+ |
|
☀️ Test successful - checks-actions |
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.
No description provided.