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

Rollup of 15 pull requests #130007

Closed
wants to merge 33 commits into from

Conversation

workingjubilee
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

sthibaul and others added 30 commits July 29, 2024 16:11
Determining this path occasionally fails locally for unknown reasons, resulting
in the build failing with an unhelpful `StripPrefixError(())` panic message.

In order to track down why that's happening, include some relevant information
in the panic message when that failure occurs.
We recently had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast")
when building tools that rely on rustc. This patch fixes that by copying those files as required.

Signed-off-by: onur-ozkan <work@onurozkan.dev>
It turns out the stars did not actually align for this to get released
in Rust 1.81 alas. Full tier 2 status for `wasm32-wasip2` required two
PRs:

* rust-lang#126967 - this made it into Rust 1.81
* rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead

This wasn't caught until just after today's release so the plan is to
remove the release notes for 1.81 and coordinate to instead add these as
release notes to 1.82.
…llot

Add an internal lint that warns when accessing untracked data

Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions.

I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough.

r? ```@oli-obk```
… r=lcnr

Check WF of source type's signature on fn pointer cast

This PR patches the implied bounds holes slightly for rust-lang#129005, rust-lang#25860.

Like most implied bounds related unsoundness fixes, this isn't complete w.r.t. higher-ranked function signatures, but I believe it implements a pretty good heuristic for now.

### What does this do?

This PR makes a partial patch for a soundness hole in a `FnDef` -> `FnPtr` "reifying" pointer cast where we were never checking that the signature we are casting *from* is actually well-formed. Because of this, and because `FnDef` doesn't require its signature to be well-formed (just its predicates must hold), we are essentially allowed to "cast away" implied bounds that are assumed within the body of the `FnDef`:

```
fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

fn bad<'short, T>(x: &'short T) -> &'static T {
    let f: fn(_, &'short T) -> &'static T = foo;
    f(&&(), x)
}
```

In this example, subtyping ends up casting the `_` type (which should be `&'static &'short ()`) to some other type that no longer serves as a "witness" to the lifetime relationship `'short: 'static` which would otherwise be required for this call to be WF. This happens regardless of if `foo`'s lifetimes are early- or late-bound.

This PR implements two checks:
1. We check that the signature of the `FnDef` is well-formed *before* casting it. This ensures that there is at least one point in the MIR where we ensure that the `FnDef`'s implied bounds are actually satisfied by the caller.
2. Implements a special case where if we're casting from a higher-ranked `FnDef` to a non-higher-ranked, we instantiate the binder of the `FnDef` with *infer vars* and ensure that it is a supertype of the target of the cast.

The (2.) is necessary to validate that these pointer casts are valid for higher-ranked `FnDef`. Otherwise, the example above would still pass even if `help`'s `'a` lifetime were late-bound.

### Further work

The WF checks for function calls are scattered all over the MIR. We check the WF of args in call terminators, we check the WF of `FnDef` when we create a `const` operand referencing it, and we check the WF of the return type in rust-lang#115538, to name a few.

One way to make this a bit cleaner is to simply extend rust-lang#115538 to always check that the signature is WF for `FnDef` types. I may do this as a follow-up, but I wanted to keep this simple since this leads to some pretty bad NLL diagnostics regressions, and AFAICT this solution is *complete enough*.

### Crater triage

Done here: rust-lang#129021 (comment)

r? lcnr
…m-const, r=lcnr

fix ICE when `asm_const` and `const_refs_to_static` are combined

fixes rust-lang#129462
fixes rust-lang#126896
fixes rust-lang#124164

I think this is a case that was missed in the fix for rust-lang#125558, which inserts a type error in the case of an invalid (that is, non-integer) type being passed to an asm `const` operand.

I'm not 100% sure that `span_mirbug_and_err` is the right macro here, but it is used earlier with `builtin_deref` and seems to do the trick.

r? ```@lcnr```
…tmcm

clarify that addr_of creates read-only pointers

Stacked Borrows does make this UB, but Tree Borrows does not. This is tied up with rust-lang#56604 and other UCG discussions. Also see [this collection of links](Rust-for-Linux/linux#950 (comment)) where rustc treats `addr_of!` as a "non-mutating use".

So, let's better be careful for now.
…arsan68

bootstrap: Try to track down why `initial_libdir` sometimes fails

When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this:

```text
thread 'main' panicked at src/lib.rs:341:14:
called `Result::unwrap()` on an `Err` value: StripPrefixError(())
```

It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs.

Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have.

So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
… r=albertlarsan68

Make `./x.py <cmd> compiler/<crate>` aware of the crate's features

Does not fix rust-lang#129727 on its own as the way the parallel-compiler cfg and feature flags are setup being generally incompatible with `resolver = 2` but it progresses on the issue. But this should in theory allow compiler crates to work that do not depend on the parallel compiler stuff (so some leaf crates).
…rors

explain why Rvalue::Len still exists

I just spent a bit of time trying to remove this until I realized why that's non-trivial. Let's document that for the next person. :)
…=Kobzol

copy rustc rustlib artifacts from ci-rustc

We recently (since rust-lang#129311) had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast") when building tools that rely on rustc. This patch fixes that by copying those files as required.

r? Kobzol

Blocker for rust-lang#122709
…pietroalbini

Add compat note for trait solver change

r? ```@pietroalbini``` ```@BoxyUwU```

cc ```@lcnr```
…separators, r=tgross35

Add digit separators in `Duration` examples

```@rustbot``` label A-docs
Temporarily remove fmease from the review rotation

Namely for like a week. I seriously need to work off my review backlog!

r? fmease
…bertlarsan68

forward linker option to lint-docs

This fixes an error found when building the doc for a cross-built toolchain.

```
warning: the code example in lint `unstable_syntax_pre_expansion` in /buildroots/chenx97/rustc-1.80.1-src/compiler/rustc_lint_defs/src/builtin.rs failed to generate the expected output: did not find lint `unstable_syntax_p
re_expansion` in output of example, got:

error: linking with `cc` failed: exit status: 1
...
```
Closes: rust-lang#129956
…errors

Make `Ty::boxed_ty` return an `Option`

Looks like a good place to use Rust's type system.

---

Most of https://github.com/rust-lang/rust/blob/4ac7bcbaad8d6fd7a51bdf1b696cbc3ba4c796cf/compiler/rustc_middle/src/ty/sty.rs#L971-L1963 looks like it could be moved to `TyKind` (then I guess  `Ty` should be made to deref to `TyKind`).
…release-notes, r=pietroalbini

Remove wasm32-wasip2's tier 2 status from release notes

It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for `wasm32-wasip2` required two PRs:

* rust-lang#126967 - this made it into Rust 1.81
* rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead

This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.
@rustbot rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Sep 6, 2024
@workingjubilee
Copy link
Member Author

@bors r+ rollup=never p=15

@bors
Copy link
Contributor

bors commented Sep 6, 2024

📌 Commit 613c36d has been approved by workingjubilee

It is now in the queue for this repository.

@bors 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 Sep 6, 2024
@rust-log-analyzer
Copy link
Collaborator

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
#16 2.817 Building wheels for collected packages: reuse
#16 2.818   Building wheel for reuse (pyproject.toml): started
#16 3.066   Building wheel for reuse (pyproject.toml): finished with status 'done'
#16 3.067   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132715 sha256=dfa09868353292d98f811d3efdb0d54d07389e808efc71d68e3b93c514bf8bec
#16 3.067   Stored in directory: /tmp/pip-ephem-wheel-cache-z2l6zbr7/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#16 3.070 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#16 3.472 Successfully installed attrs-23.2.0 binaryornot-0.4.4 boolean-py-4.0 chardet-5.2.0 jinja2-3.1.4 license-expression-30.3.0 markupsafe-2.1.5 python-debian-0.1.49 reuse-4.0.3 tomlkit-0.13.0
#16 3.472 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#16 DONE 3.6s
---
  |
3 | pub fn target() -> Target {
  | ---^^^^^^^^^^^^^^^^^^^^^^
  | |
  | help: consider restricting its visibility: `pub(crate)`
  = help: or consider exporting it for use by other crates
  = note: `-D unreachable-pub` implied by `-D warnings`
  = help: to override `-D warnings` add `#[allow(unreachable_pub)]`

@workingjubilee
Copy link
Member Author

?

@bors r-

@bors 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 Sep 6, 2024
@workingjubilee workingjubilee deleted the rollup-6zfqjfn branch September 9, 2024 05:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.