When you make a change to the diagnostic lints, it uses the old version
of the lints with stage 1 and the new version with stage 2, which often
leads to failures in stage 1. Let's just stick to stage 2.
Rollup of 10 pull requests
Successful merges:
- #120976 (constify a couple thread_local statics)
- #121683 (Fix LVI tests after frame pointers are enabled by default)
- #121703 (Add a way to add constructors for `rustc_type_ir` types)
- #121732 (Improve assert_matches! documentation)
- #121928 (Extract an arguments struct for `Builder::then_else_break`)
- #121939 (Small enhancement to description of From trait)
- #121968 (Don't run test_get_os_named_thread on win7)
- #121969 (`ParseSess` cleanups)
- #121977 (Doc: Fix incorrect reference to integer in Atomic{Ptr,Bool}::as_ptr.)
- #121994 (Update platform-support.md with supported musl version)
r? `@ghost`
`@rustbot` modify labels: rollup
Update platform-support.md with supported musl version
This just reflects the current status quo, there is no actual change here since the update to musl 1.2.3 occurred in #107129 and was approved in https://github.com/rust-lang/compiler-team/issues/572.
I also normalized all mentions of musl libc to "musl" (non-capitalized per the project's site and Wikipedia page).
r? ``@ehuss``
Doc: Fix incorrect reference to integer in Atomic{Ptr,Bool}::as_ptr.
I am assuming "resulting integer" is an error, since we are talking about pointers and booleans here. Seems like it was missed while copy & pasting the docs from the integer versions. I also checked the rest of the docs, and this was the only mention of integers.
Don't run test_get_os_named_thread on win7
This test won't work on windows 7, as the Thread::set_name function is not implemented there (win7 does not provide a documented mechanism to set thread names).
Extract an arguments struct for `Builder::then_else_break`
Most of this method's arguments are usually or always forwarded as-is to recursive invocations.
Wrapping them in a dedicated struct allows us to document each struct field, and lets us use struct-update syntax to indicate which arguments are being modified when making a recursive call.
---
While trying to understand the lowering of `if` expressions, I found it difficult to keep track of the half-dozen arguments passed through to every call to `then_else_break`. I tried switching over to an arguments struct, and I found that it really helps to make sense of what each argument does, and how each call is modifying the arguments.
I have some further ideas for how to streamline these recursive calls, but I've kept those out of this PR so that it's a pure refactoring with no behavioural changes.
Improve assert_matches! documentation
This new documentation tries to limit the impact of the conceptual pitfall, that the if guard relaxes the constraint, when really it tightens it. This is achieved by changing the text and examples. The previous documentation also chose a rather weird and non-representative example for the if guard, that made it needlessly complicated to understand.
Add a way to add constructors for `rustc_type_ir` types
Introduces a module called `rustc_type_ir`, in which we can place traits which are named `Ty`/`Region`/`Const`/etc. which expose constructors for the `rustc_type_ir` types. This means we can construct things `Interner::Ty` with `Ty::new_x(...)`, which is needed to uplift the new trait solver into an interner-agnostic crate.
These traits are placed into a *separate* module because they're only intended to be used in interner-agnostic code, and they should mirror the constructors that are provided by the inherent constructor methods in `rustc_middle`.
Putting this up for vibe-check mostly. I haven't copied over any of the type constructors, except for one to create bound types for use in the canonicalizer.
r? lcnr
Fix LVI tests after frame pointers are enabled by default
#121203 enables frame pointers by default. This affects LVI mitigations for the `x86_64-fortanix-unknown-sgx` target. LVI remained mitigated correctly, but the tests were too strict.
``@nshyrei`` , ``@jethrogb``
Existing names for values of this type are `sess`, `parse_sess`,
`parse_session`, and `ps`. `sess` is particularly annoying because
that's also used for `Session` values, which are often co-located, and
it can be difficult to know which type a value named `sess` refers to.
(That annoyance is the main motivation for this change.) `psess` is nice
and short, which is good for a name used this much.
The commit also renames some `parse_sess_created` values as
`psess_created`.
Add a new `wasm32-wasip1` target to rustc
This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs:
* https://github.com/rust-lang/compiler-team/issues/607
* https://github.com/rust-lang/compiler-team/issues/695
In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](https://github.com/rust-lang/rust/pull/119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
This test won't work on windows 7, as the Thread::set_name function is
not implemented there (win7 does not provide a documented mechanism to
set thread names).
Rollup of 3 pull requests
Successful merges:
- #121130 (Suggest moving definition if non-found macro_rules! is defined later)
- #121912 (Properly deal with GATs when looking for method chains to point at)
- #121927 (Add a proper `with_no_queries` to printing)
r? `@ghost`
`@rustbot` modify labels: rollup
Most of this method's arguments are usually or always forwarded as-is to
recursive invocations.
Wrapping them in a dedicated struct allows us to document each struct field,
and lets us use struct-update syntax to indicate which arguments are being
modified when making a recursive call.
Properly deal with GATs when looking for method chains to point at
Fixes#121898.
~~While it prevents an ICE and the structured suggestion is correct, the method chain diagnostic notes are weird / useless / incorrect judging by a quick look. I guess I should improve that in this PR.~~ Sufficiently taken care of.
r? estebank or compiler-errors (#105332, #105674).
Rollup of 5 pull requests
Successful merges:
- #121248 (Move some tests)
- #121528 (Consider middle segments of paths in `unused_qualifications`)
- #121749 (Don't lint on executable crates with `non_snake_case` names)
- #121935 (library/ptr: mention that ptr::without_provenance is equivalent to deriving from the null ptr)
- #121945 (Run some ui-fulldeps tests on stage 1 again)
r? `@ghost`
`@rustbot` modify labels: rollup
Run some ui-fulldeps tests on stage 1 again
This is the second time I'm doing this... I'm starting to feel like stage1 ui-fulldeps tests were a mistake. Maybe I should have just put `#[cfg(bootstrap)]` there to let the bootstrap bumper fix it.
`@George-lewis` :)
finishes https://github.com/rust-lang/rust/pull/119088#issuecomment-1890389583
library/ptr: mention that ptr::without_provenance is equivalent to deriving from the null ptr
This might help clarify why you can't do memory accesses with it.
Consider middle segments of paths in `unused_qualifications`
Currently `unused_qualifications` looks at the last segment of a path to see if it can be trimmed, this PR extends the check to the middle segments also
```rust
// currently linted
use std::env::args();
std::env::args(); // Removes `std::env::`
```
```rust
// newly linted
use std::env;
std::env::args(); // Removes `std::`
```
Paths with generics in them are now linted as long as the part being trimmed is before any generic args, e.g. it will now suggest trimming `std::vec::` from `std::vec::Vec<usize>`
Paths with any segments that are from an expansion are no longer linted
Fixes#100979Fixes#96698
This is the second time I'm doing this... I'm starting to feel like
stage1 ui-fulldeps tests were a mistake. Maybe I should have just put
`#[cfg(bootstrap)]` there to let the bootstrap bumper fix it.
Nicholas Nethercote