Perf regression fix
The only thing changed from the previous PR is that I removed `output_is_inhabited` from hot path, and hide it behind condition, so now it will compute it less frequent
follow up on https://github.com/rust-lang/rust/pull/149664
move eii tests
Just a little housekeeping. This feature is getting a lot of tests, so it felt good to put some tests for type checking in its own folder to organise a little. Should be trivial!
mir_build: Don't use a mixture of THIR pattern kinds for pin-patterns
While looking for improvements to match-lowering, I had been trying to figure out why pin-patterns sometimes use `PatKind::Deref` and sometimes use `PatKind::DerefPattern`, which seemed confusing to me. In particular, both pattern kinds are being used with an inner type of `&` or `&mut`, which is very surprising.
The conclusion I came to was that `DerefPattern` (normally associated with calls to Deref/DerefMut) was only being used for *implicit* pin-patterns produced by match-ergonomics adjustment, whereas `Deref` was being used for explicit pin-patterns.
The inconsistency seems like a mistake to me, so this PR removes all uses of `DerefPattern` for pin-patterns, and consistently uses `PatKind::Deref` for pin-patterns instead. I'm not entirely happy with that outcome, because I think pin-patterns should probably have their own `thir::PatKind` variant, but this change will at least make that easier to achieve in a later PR.
r? Nadrieril
Prefer remapping the relative `library/` and `compiler/` directories
This is done to avoid leaking the relative paths to the standard library after the overall of filenames in rust-lang/rust#149709.
Noted that the paths were already leaking before, but to a lesser extent since most (but not all) the paths embedded in the distributed `rlib` were absolute.
In general Cargo compiles workspace members with relative paths, so it's better anyway to remap the relative path.
In addition to our tests I have manually confirmed that it also works as expected for the printed diagnostics paths.
cf. https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/remapping.20of.20the.20standard.20library/near/564093571
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#147430 (cg_llvm: More preparation for moving FFI bindings to `rustc_llvm`)
- rust-lang/rust#149815 (Add regression test for rust-lang/rust#120189)
- rust-lang/rust#150127 (Port `#[rustc_lint_untracked_query_information]` and `#[rustc_lint_diagnostics]` to using attribute parsers)
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for #120189
This PR adds regression tests for rust-lang/rust#120189.
I added tests to verify vectorization of loops inside closures.
Don't treat asserts as a call in cross-crate inlining
Making functions with calls in their bodies automatically cross-crate-inlinable tends to tank incremental build times. Though assert terminators are _like_ calls, they don't exhibit the same behavior.
Subtree sync for rustc_codegen_cranelift
Nothing too exciting since the last sync.
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Fixed ICE for EII with multiple defaults due to duplicate definition in nameres
r? ``@jieyouxu`` (since you looked at the other one)
Fixes https://github.com/rust-lang/rust/issues/149982
Previously a [fix was proposed](https://github.com/rust-lang/rust/pull/149985) by ``@SATVIKsynopsis`` which I marked as co-author on the first commit for the test they contributed. I'm closing this previous PR.
Duplicate definitions of EII defaults shouldn't be possible. I want to still panic on them, since I want to know when other bugs exist. However, in this case the duplicate was caused by something more subtle: both eiis have the same name, and as such a "duplicate definition" error is given. However, the compiler gracefully continues compiling despite that, assuming only one of the two EIIs is actually defined.
Both defaults then name resolve, and find the same single remaining EII, and both register themselves to be its default, breaking the single-default assumption.
The solution: I added a span-delayed-bug, to make sure we only panic if we hadn't previously had this duplicate definition name resolution error.
Thanks to ``@SATVIKsynopsis`` for their attempt. Adding a diagnostic here could make some sense, but nonetheless I think this is the better solution here <3
Also thanks to ``@yaahc`` for debugging help, she made me understand the name resolution of the situation so much better and is just lovely in general :3
The last commit is something I tried during debugging, which felt like a relevant test to add (one where both eiis also have the same function name)
tests/run-make-cargo/same-crate-name-and-macro-name: New regression test
Closes https://github.com/rust-lang/rust/issues/71259 which just **E-needs-test**. See https://github.com/rust-lang/rust/issues/71259#issuecomment-615879925 for a good description of what we should test (which we do in this PR).
The project we add fails with an old nightly without the fix:
```console
$ cargo +nightly-2020-03-10 run
Compiling consumer v0.1.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer)
Finished dev [unoptimized + debuginfo] target(s) in 0.14s
Running `target/debug/consumer`
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `"version 1"`,
right: `"version 2"`', src/main.rs:6:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
and passes with a recent toolchain:
```console
$ cargo run
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v1/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
warning: /home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v2/Cargo.toml: no edition set: defaulting to the 2015 edition while the latest is 2024
Compiling mylib v2.0.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v2)
Compiling mylib v1.0.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/mylib_v1)
Compiling consumer v0.1.0 (/home/martin/src/rust-same-crate-same-macro/tests/run-make-cargo/same-crate-name-and-macro-name/consumer)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.14s
Running `target/debug/consumer`
```
in other words, the test tests what it should and will catch regressions.
std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features
This synchronizes the list with the current state of `sysctl` on macOS “Tahoe” 26.2.
r? ``@Amanieu``
Support recursive delegation
This PR adds support for recursive delegations and is a part of the delegation feature rust-lang/rust#118212.
r? ``@petrochenkov``
Generate macro expansion for rust compiler crates docs
This enables the `--generate-macro-expansion` rustdoc flag, generating possibility to expand macros directly in source code pages (https://github.com/rust-lang/rust/pull/137229).
Needed this new feature when I was working on https://github.com/rust-lang/rust/pull/149919 and I thought "why not enable it by default?". So here we go.
Not too sure who to r? here so:
r? ``@kobzol``
Suggest struct pattern when destructuring Range with .. syntax
implemented a new diagnostic in rustc_resolve to detect invalid range destructuring attempts (e.g., let start..end = range). The fix identifies when resolution fails for identifiers acting as range bounds specifically handling cases where bounds are parsed as expressions and suggests the correct struct pattern syntax (std::ops::Range { start, end }). This replaces confusing "cannot find value" errors with actionable help, verified by a new UI test covering various identifier names.
Fixesrust-lang/rust#149777
Set -Cpanic=abort in windows-msvc stack protector tests
I ran into a test failure with the 32-bit windows test on https://github.com/rust-lang/rust/pull/117192, one of the tests has been incorrectly passing (until my change!) because it is picking up the stack protector from another function. I've tried to prevent that happening again by adding CHECK-DAGs for the start and end of each function.
I've also done my best to correct the comments, some were based on the fact that we used to run these tests with unwinding panics, but LLVM doesn't add protectors to function with SEH funclets so it's must more straightforward for these tests to use `-Cpanic=abort`.
Expand `str_as_str` to more types
Tracking issue: rust-lang/rust#130366
ACP: https://github.com/rust-lang/libs-team/issues/643
This PR expands `str_from_str` feature and adds analogous methods to more types. Namely:
- `&CStr`
- `&[T]`, `&mut [T]`
- `&OsStr`
- `&Path`
- `&ByteStr`, `&mut ByteStr` (tracking issue: rust-lang/rust#134915) (technically was not part of ACP)
Make closure capturing have consistent and correct behaviour around patterns
Reference PR:
- https://github.com/rust-lang/reference/pull/1837
This PR has two goals:
- firstly, it fixesrust-lang/rust#137467. In order to do so, it needs to introduce a small breaking change surrounding the interaction of closure captures with matching against enums with uninhabited variants. Yes – to fix an ICE!
- this also fixesrust-lang/rust#138973, a slightly different case with the same root cause.
- likewise, fixesrust-lang/rust#140011.
- secondly, it fixesrust-lang/rust#137553, making the closure capturing rules consistent between `let` patterns and `match` patterns. This is new insta-stable behavior.
## Background
This change concerns how precise closure captures interact with patterns. As a little known feature, patterns that require inspecting only part of a value will only cause that part of the value to get captured:
```rust
fn main() {
let mut a = (21, 37);
// only captures a.0, writing to a.1 does not invalidate the closure
let mut f = || {
let (ref mut x, _) = a;
*x = 42;
};
a.1 = 69;
f();
}
```
I was not able to find any discussion of this behavior being introduced, or discussion of its edge-cases, but it is [documented in the Rust reference](https://doc.rust-lang.org/reference/types/closure.html#r-type.closure.capture.precision.wildcard).
The currently stable behavior is as follows:
- if any pattern contains a binding, the place it binds gets captured (implemented in current `walk_pat`)
- patterns in refutable positions (`match`, `if let`, `let ... else`, but not destructuring `let` or destructuring function parameters) get processed as follows (`maybe_read_scrutinee`):
- if matching against the pattern will at any point require inspecting a discriminant, or it includes a variable binding not followed by an ``@`-pattern,` capture *the entire scrutinee* by reference
You will note that this behavior is quite weird and it's hard to imagine a sensible rationale for at least some of its aspects. It has the following issues:
- firstly, it assumes that matching against an irrefutable pattern cannot possibly require inspecting any discriminants. With or-patterns, this isn't true, and it is the cause of the rust-lang/rust#137467 ICE.
- secondly, the presence of an ``@`-pattern` doesn't really have any semantics by itself. This is the weird behavior tracked as rust-lang/rust#137553.
- thirdly, the behavior is different between pattern-matching done through `let` and pattern-matching done through `match` – which is a superficial syntactic difference
This PR aims to address all of the above issues. The new behavior is as follows:
- like before, if a pattern contains a binding, the place it binds gets captured as required by the binding mode
- if matching against the pattern requires inspecting a disciminant, the place whose discriminant needs to be inspected gets captured by reference
"requires inspecting a discriminant" is also used here to mean "compare something with a constant" and other such decisions. For types other than ADTs, the details are not interesting and aren't changing.
## The breaking change
During closure capture analysis, matching an `enum` against a constructor is considered to require inspecting a discriminant if the `enum` has more than one variant. Notably, this is the case even if all the other variants happen to be uninhabited. This is motivated by implementation difficulties involved in querying whether types are inhabited before we're done with type inference – without moving mountains to make it happen, you hit this assert: 43f0014ef0/compiler/rustc_middle/src/ty/inhabitedness/mod.rs (L121)
Now, because the previous implementation did not concern itself with capturing the discriminants for irrefutable patterns at all, this is a breaking change – the following example, adapted from the testsuite, compiles on current stable, but will not compile with this PR:
```rust
#[derive(Clone, Copy, PartialEq, Eq, Debug)]
enum Void {}
pub fn main() {
let mut r = Result::<Void, (u32, u32)>::Err((0, 0));
let mut f = || {
let Err((ref mut a, _)) = r;
*a = 1;
};
let mut g = || {
//~^ ERROR: cannot borrow `r` as mutable more than once at a time
let Err((_, ref mut b)) = r;
*b = 2;
};
f();
g();
assert_eq!(r, Err((1, 2)));
}
```
## Is the breaking change necessary?
One other option would be to double down, and introduce a set of syntactic rules for determining whether a sub-pattern is in an irrefutable position, instead of querying the types and checking how many variants there are.
**This would not eliminate the breaking change,** but it would limit it to more contrived examples, such as
```rust
let ((true, Err((ref mut a, _, _))) | (false, Err((_, ref mut a, _)))) = x;
```
In this example, the `Err`s would not be considered in an irrefutable position, because they are part of an or-pattern. However, current stable would treat this just like a tuple `(bool, (T, U, _))`.
While introducing such a distinction would limit the impact, I would say that the added complexity would not be commensurate with the benefit it introduces.
## The new insta-stable behavior
If a pattern in a `match` expression or similar has parts it will never read, this part will not be captured anymore:
```rust
fn main() {
let mut a = (21, 37);
// now only captures a.0, instead of the whole a
let mut f = || {
match a {
(ref mut x, _) => *x = 42,
}
};
a.1 = 69;
f();
}
```
Note that this behavior was pretty much already present, but only accessible with this One Weird Trick™:
```rust
fn main() {
let mut a = (21, 37);
// both stable and this PR only capture a.0, because of the no-op `@-pattern`
let mut f = || {
match a {
(ref mut x @ _, _) => *x = 42,
}
};
a.1 = 69;
f();
}
```
## The second, more practically-relevant breaking change
After running crater, we have discovered that the aforementioned insta-stable behavior, where sometimes closures will now capture less, can also manifest as a breaking change. This is because it is possible that previously a closure would capture an entire struct by-move, and now it'll start capturing only part of it – some by move, and some by reference. This then causes the closure to have a more restrictive lifetime than it did previously.
See:
- https://github.com/rust-lang/rust/pull/138961#issuecomment-2761888557
- https://github.com/EC-labs/cec-assignment/pull/1
- https://github.com/tryandromeda/andromeda/pull/43
## Implementation notes
The PR has two main commits:
- "ExprUseVisitor: properly report discriminant reads" makes `walk_pat` perform all necessary capturing. This is the part that fixesrust-lang/rust#137467.
- "ExprUseVisitor: remove maybe_read_scrutinee" removes the unnecessary "capture the entire scrutinee" behavior, fixing rust-lang/rust#137553.
The new logic stops making the distinction between one particular example that used to work, and another ICE, tracked as rust-lang/rust#119786. As this requires an unstable feature, I am leaving this as future work.
[rustdoc] Fix invalid handling of field followed by negated macro call
This is the bug uncovered in https://github.com/rust-lang/rust/pull/150022. Once fixed Ill rebuild all compiler docs and see if we can enable the option for compiler docs. =D
It's a weird case where we extracted some tokens out of the iterator and then, when checking next items (from this iterator), it didn't find the `:` token, and therefore badly assumed the token kind.
The solution I came up with is to instead not extract tokens from the iterator and to count how many tokens are in the current path. So when iterate over the items, instead of having a mix of extracted tokens and tokens still inside the iterator, we now only iterate over the iterator.
The biggest change here is that `get_full_ident_path` will return an option instead of a `Vec`, and if it's contains `:` (one, not two), then it will return `None` and the `:` will be handled like any token and not like a path (which is more correct imo).
r? `@yotamofek`
