Skip to content
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

Automatic Rustup #3537

Merged
merged 42 commits into from
May 3, 2024
Merged

Automatic Rustup #3537

merged 42 commits into from
May 3, 2024

Conversation

github-actions[bot]
Copy link

@github-actions github-actions bot commented May 3, 2024

No description provided.

bors and others added 30 commits April 26, 2024 11:16
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.
bors and others added 11 commits May 1, 2024 22:22
…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?
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
@RalfJung
Copy link
Member

RalfJung commented May 3, 2024

@bors r+

@bors
Copy link
Contributor

bors commented May 3, 2024

📌 Commit 54d8525 has been approved by RalfJung

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented May 3, 2024

⌛ Testing commit 54d8525 with merge 96b659b...

bors added a commit that referenced this pull request May 3, 2024
@bors
Copy link
Contributor

bors commented May 3, 2024

💔 Test failed - checks-actions

@RalfJung
Copy link
Member

RalfJung commented May 3, 2024

@bors r+

@bors
Copy link
Contributor

bors commented May 3, 2024

📌 Commit 9de0f4b has been approved by RalfJung

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented May 3, 2024

⌛ Testing commit 9de0f4b with merge 495af0d...

@bors
Copy link
Contributor

bors commented May 3, 2024

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 495af0d to master...

@bors bors merged commit 495af0d into master May 3, 2024
8 checks passed
@bors bors deleted the rustup-2024-05-03 branch May 3, 2024 07:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants