Simplify array length mismatch error reporting (to not try to turn consts into target usizes)
This changes `TypeError::FixedArrayLen` to use `ExpectedFound<ty::Const<'tcx>>` (instead of `ExpectedFound<u64>`), and renames it to `TypeError::ArrayLen`. This allows us to avoid a `try_to_target_usize` call in the type relation, which ICEs when we have a scalar of the wrong bit length (i.e. u8).
This also makes `structurally_relate_tys` to always use this type error kind any time we have a const mismatch resulting from relating the array-len part of `[T; N]`.
This has the effect of changing the error message we issue for array length mismatches involving non-valtree consts. I actually quite like the change, though, since before:
```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
| ------- expected `[u8; M]` because of return type
LL | [0; N]
| ^^^^^^ expected `M`, found `N`
|
= note: expected array `[u8; M]`
found array `[u8; N]`
```
and after, which I think is far less verbose:
```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
| ------- expected `[u8; M]` because of return type
LL | [0; N]
| ^^^^^^ expected an array with a size of M, found one with a size of N
```
The only questions I have are:
1. Should we do something about backticks here? Right now we don't backtick either fully evaluated consts like `2`, or rigid consts like `Foo::BAR`.... but maybe we should? It seems kinda verbose to do for numbers -- maybe we could intercept those specifically.
2. I guess we may still run the risk of leaking unevaluated consts into error reporting like `2 + 1`...?
r? ``@BoxyUwU``
Fixes#126359Fixes#131101
No need to re-sort existential preds in relate impl
We already assert that these predicates are in the right ordering in `mk_poly_existential_predicates`.
r? types
Remove the `DefinitelyInitializedPlaces` analysis.
Its only use is in the `tests/ui/mir-dataflow/def_inits-1.rs` where it is tested via `rustc_peek_definite_init`.
Also, it's probably buggy. It's supposed to be the inverse of `MaybeUninitializedPlaces`, and it mostly is, except that `apply_terminator_effect` is a little different, and `apply_switch_int_edge_effects` is missing. Unlike `MaybeUninitializedPlaces`, which is used extensively in borrow checking, any bugs in `DefinitelyInitializedPlaces` are easy to overlook because it is only used in one small test.
This commit removes the analysis. It also removes
`rustc_peek_definite_init`, `Dual` and `MeetSemiLattice`, all of which are no longer needed.
r? ``@cjgillot``
Inline ExprPrecedence::order into Expr::precedence
The representation of expression precedence in rustc_ast has been an obstacle to further improvements in the pretty-printer (continuing from #119105 and #119427).
Previously the operation of *"does this expression have lower precedence than that one"* (relevant for parenthesis insertion in macro-generated syntax trees) consisted of 3 steps:
1. Convert `Expr` to `ExprPrecedence` using `.precedence()`
2. Convert `ExprPrecedence` to `i8` using `.order()`
3. Compare using `<`
As far as I can guess, the reason for the separation between `precedence()` and `order()` was so that both `rustc_ast::Expr` and `rustc_hir::Expr` could convert as straightforwardly as possible to the same `ExprPrecedence` enum, and then the more finicky logic performed by `order` could be present just once.
The mapping between `Expr` and `ExprPrecedence` was intended to be as straightforward as possible:
```rust
match self.kind {
ExprKind::Closure(..) => ExprPrecedence::Closure,
...
}
```
although there were exceptions of both many-to-one, and one-to-many:
```rust
ExprKind::Underscore => ExprPrecedence::Path,
ExprKind::Path(..) => ExprPrecedence::Path,
...
ExprKind::Match(_, _, MatchKind::Prefix) => ExprPrecedence::Match,
ExprKind::Match(_, _, MatchKind::Postfix) => ExprPrecedence::PostfixMatch,
```
Where the nature of `ExprPrecedence` becomes problematic is when a single expression kind might be associated with multiple different precedence levels depending on context (outside the expression) and contents (inside the expression). For example consider what is the precedence of an ExprKind::Closure `$closure`. Well, on the left-hand side of a binary operator it would need parentheses in order to avoid the trailing binary operator being absorbed into the closure body: `($closure) + Rhs`, so the precedence is something lower than that of `+`. But on the right-hand side of a binary operator, a closure is just a straightforward prefix expression like a unary op, which is a relatively high precedence level, higher than binops but lower than method calls: `Lhs + $closure` is fine without parens but `($closure).method()` needs them. But as a third case, if the closure contains an explicit return type, then the precedence is an even higher level than that, never needing parenthesization even in a binop left-hand side or method call: `|| -> bool { false } + Rhs` or `|| -> bool { false }.method()`.
You can see that trying to capture all of this resolution about expressions into `ExprPrecedence` violates the intention of `ExprPrecedence` being a straightforward one-to-one correspondence from each AST and HIR `ExprKind` variant. It would be possible to attempt that by doing stuff like `ExprPrecedence::Closure(Side::Leading, ReturnType::No)`, but I don't foresee the original envisioned benefit of the `precedence()`/`order()` distinction being retained in this approach. Instead I want to move toward a model that Syn has been using successfully. In Syn, there is a Precedence enum but it differs from rustc in the following ways:
- There are [relatively few variants](https://github.com/dtolnay/syn/blob/2.0.87/src/precedence.rs#L11-L47) compared to rustc's `ExprPrecedence`. For example there is no distinction at the precedence level between returns and closures, or between loops and method calls.
- We distinguish between [leading](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L293) and [trailing](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L309) precedence, taking into account an expression's context such as what token follows it (for various syntactic bail-outs in Rust's grammar, like ambiguities around break-with-value) and how it relates to operators from the surrounding syntax tree.
- There are no hardcoded mysterious integer quantities like rustc's `PREC_CLOSURE = -40`. All precedence comparisons are performed via PartialOrd on a C-like enum.
This PR is just a first step in these changes. As you can tell from Syn, I definitely think there is value in having a dedicated type to represent precedence, instead of what `order()` is doing with `i8`. But that is a whole separate adventure because rustc_ast doesn't even agree consistently on `i8` being the type for precedence order; `AssocOp::precedence` instead uses `usize` and there are casts in both directions. It is likely that a type called `ExprPrecedence` will re-appear, but it will look substantially different from the one that existed before this PR.
Use ReadCache for archive reading in bootstrap
Address expensive archive reading in bootstrap. This fixes https://github.com/rust-lang/rust/issues/133268
Enable the `std` feature of `object` to use `ReadCache` instead of reading the entire archive file into memory to check for headers. This takes minimal extra time to compile compared to introducing other expensive dependencies to `bootstrap`.
r? jieyouxu
Tweak parameter mismatch explanation to not say `{unknown}`
* Tweak parameter mismatch explanation not to call parameters with no identifier `{unknown}`
* Say "both" when there are two parameters
* Backtick a type parameter name for consistency
the emscripten OS no longer exists on non-wasm targets
https://github.com/rust-lang/rust/pull/117338 removed our asmjs targets, which AFAIK means that emscripten only exists on wasm targets. However at least one place in the code still checked "is wasm or is emscripten". Let's fix that.
Cc ```@workingjubilee```
Refactor `where` predicates, and reserve for attributes support
Refactor `WherePredicate` to `WherePredicateKind`, and reserve for attributes support in `where` predicates.
This is a part of #115590 and is split from #132388.
r? petrochenkov
`ResultsCursor` currently owns its `Results`. But sometimes the
`Results` is needed again afterwards. So there is
`ResultsCursor::into_results` for extracting the `Results`, which leads
to some awkwardness.
This commit adds `ResultsHandle`, a `Cow`-like type that can either
borrow or own a a `Results`. `ResultsCursor` now uses it. This is good
because some `ResultsCursor`s really want to own their `Results`, while
others just want to borrow it.
We end with with a few more lines of code, but get some nice cleanups.
- `ResultsCursor::into_results` and `Formatter::into_results` are
removed.
- `write_graphviz_results` now just borrows a `Results`, instead of the
awkward "take ownership of a `Results` and then return it unchanged"
pattern.
This reinstates the cursor flexibility that was lost in #118230 -- which
removed the old `ResultsRefCursor` and `ResultsCloneCursor` types -- but
in a much simpler way. Hooray!
In `MaybeRequiresStorage::apply_before_statement_effect`, call
`transfer_function` directly, as is already done in
`MaybeRequiresStorage::apply_before_terminator_effect`. This makes it clear
that the operation doesn't rely on the `MaybeBorrowedLocals` results.
Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)
This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.
This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: https://github.com/rust-lang/rust/issues/133416). If the feature is not enabled, only clober is supported as before.
| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |
This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313
In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.
Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in https://github.com/rust-lang/rust/issues/130869.
cc https://github.com/rust-lang/rust/issues/130869 about vector facility support in s390x
cc https://github.com/rust-lang/rust/issues/125398 & https://github.com/rust-lang/rust/issues/116909 about f128 support in asm
`@rustbot` label +O-SystemZ +A-inline-assembly
Fix asm goto with outputs and move it to a separate feature gate
Tracking issue: #119364
This PR addresses 3 aspects of asm goto with outputs:
* Codegen is fixed. My initial implementation has an oversight which cause the output to be only stored in fallthrough path, but not in label blocks.
* Outputs can now be used with `options(noreturn)` if a label block is given.
* All of this is moved to a new feature gate, because we likely want to stabilise `asm_goto` before asm goto with outputs.
`@rustbot` labels: +A-inline-assembly +F-asm
There is a not-very-useful layering in the lexer, where
`TokenTreesReader` contains a `StringReader`. This commit combines them
and names the result `Lexer`, which is a more obvious name for it.
The methods of `Lexer` are now split across `mod.rs` and `tokentrees.rs`
which isn't ideal, but it doesn't seem worth moving a bunch of code to
avoid it.
add a test for target-feature-ABI warnings in closures and when calling extern fn
Also update the comment regarding the inheritance of target features into closures, to make it more clear that we really shouldn't do this right now.
only store valid proc macro item for doc link
Fixes#132743
The definition item can be detected if it is exported in the doc, so store these items rather than skipping.
r? `@petrochenkov`
When labels are present, the `noreturn` option really means that asm block
won't fallthrough -- if labels are present, then outputs can still be
meaningfully used.
A used function with no mappings has historically indicated a bug, but that
will no longer be the case after moving some fallible span-processing steps
into codegen.
Rollup of 6 pull requests
Successful merges:
- #133300 (inject_panic_runtime(): Avoid double negation for 'any non rlib')
- #133301 (Add code example for `wrapping_neg` method for signed integers)
- #133371 (remove is_trivially_const_drop)
- #133389 (Stabilize `const_float_methods`)
- #133398 (rustdoc: do not call to_string, it's already impl Display)
- #133405 (tidy: Distinguish between two different meanings of "style file")
r? `@ghost`
`@rustbot` modify labels: rollup
inject_panic_runtime(): Avoid double negation for 'any non rlib'
<details>
<summary>This PR originally did more things .Click to expand to see.</summary>
By not trying to inject a profiler runtime when only building an rlib. This logic already exists for the panic runtime.
This makes
RUSTFLAGS="-Cinstrument-coverage" cargo build -Zbuild-std=std,profiler_builtins
work. Note that you probably also need
`RUST_COMPILER_RT_FOR_PROFILER=$src/llvm-project/compiler-rt` in your environment.
cc #79401
# Demonstration
Before this fix you get these errors:
```console
$ rm -rf target ; RUST_COMPILER_RT_FOR_PROFILER=/home/martin/src/llvm-project/compiler-rt RUSTFLAGS="-Cinstrument-coverage" cargo +nightly build --release -Zbuild-std=std,profiler_builtins
error: `profiler_builtins` crate (required by compiler options) is not compatible with crate attribute `#![no_core]`
error[E0152]: found duplicate lang item `manually_drop`
= note: first definition in `core` loaded from /home/martin/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-d453bab70303062c.rlib
= note: second definition in the local crate (`core`)
```
With the fix the build succeeds:
```console
$ rm -rf target ; RUST_COMPILER_RT_FOR_PROFILER=/home/martin/src/llvm-project/compiler-rt RUSTFLAGS="-Cinstrument-coverage" cargo +stage1 build --release -Zbuild-std=std,profiler_builtins
Finished `release` profile [optimized] target(s) in 45.57s
```
And we can check code coverage. My example program looks like this:
```rs
fn main() {
if std::env::args_os().nth(1) == Some("write-file".into()) {
std::fs::write("hello.txt", "Hello, world!").unwrap();
} else {
println!("Hello, world!");
}
}
```
when the program prints to stdout:
```
$ LLVM_PROFILE_FILE=stdout.profraw ./target/release/hello-world
Hello, world!
```
we can see that `fs::write()` is not being used (note the `0`'s):
```console
$ /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata merge -sparse stdout.profraw -o stdout.profdata
$ /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-cov show target/release/hello-world --sources /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/std/src/fs.rs --instr-profile stdout.profdata --color | grep -A 3 'pub fn write(&mut self, write: b
ool) -> &mut Self {'
1357| 0| pub fn write(&mut self, write: bool) -> &mut Self {
1358| 0| self.0.write(write);
1359| 0| self
1360| 0| }
```
but when we print to a file:
```console
$ LLVM_PROFILE_FILE=file.profraw ./target/release/hello-world write-file
```
the code coverage shows `fs::write()` as being used (note the `1`'s):
```console
$ /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata merge -sparse file.profraw -o file.profdata
$ /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-cov show target/release/hello-world --sources /home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/std/src/fs.rs --instr-profile file.profdata --color | grep -A 3 'pub fn write(&mut self, write: bool) -> &mut Self {'
1357| 1| pub fn write(&mut self, write: bool) -> &mut Self {
1358| 1| self.0.write(write);
1359| 1| self
1360| 1| }
```
</summary>
rustc: Fail fast when compiling a source file larger than 4 GiB
Currently if you try to compile a file that is larger than 4 GiB, `rustc` will first read the whole into memory before failing.
If we can read the metadata of the file, we can fail before reading the file.
Update TRPL to add new Chapter 17: Async and Await
- Add support to `rustbook` to pass through the `-L`/`--library-path` flag to `mdbook` so that references to the `trpl` crate
- Build the `trpl` crate as part of the book tests. Make it straightforward to add other such book dependencies in the future if needed by implementing that in a fairly general way.
- Update the submodule for the book to pull in the new chapter on async and await, as well as a number of other fixes. This will happen organically/automatically in a week, too, but this lets me group this change with the next one:
- Update the compiler messages which reference the existing chapters 17–20, which are now chapters 18-21. There are only two, both previously referencing chapter 18.
- Update the UI tests which reference the compiler message outputs.
finish `Reveal` removal
After #133212 changed the `TypingMode` to be the only source of truth, this entirely rips out `Reveal`.
cc #132279
r? `@compiler-errors`
With the insertion of a new chapter 17 on async and await to _The Rust
Programming Language_, references in compiler output to later chapters
need to be updated to avoid confusing users. Redirects exist so that
users who click old links will end up in the right place anyway, but
this way users will be directed to the right URL in the first place.
show abi_unsupported_vector_types lint in future breakage reports
The lint is now riding the train to 1.84. Given that crater found no case of this lint triggering at all, IMO it's fine to make it "report in deps" already for 1.85.
Part of https://github.com/rust-lang/rust/issues/116558.
Minimally constify `Add`
* This PR removes the requirement for `impl const` to have a const stability attribute. cc ``@RalfJung`` I believe you mentioned that it would make much more sense to require `const_trait`s to have const stability instead. I agree with that sentiment but I don't think that is _required_ for a small scale experimentation like this PR. https://github.com/rust-lang/project-const-traits/issues/16 should definitely be prioritized in the future, but removing the impl check should be good for now as all callers need `const_trait_impl` enabled for any const impl to work.
* This PR is intentionally minimal as constifying other traits can become more complicated (`PartialEq`, for example, would run into requiring implementing it for `str` as that is used in matches, which runs into the implementation for slice equality which uses specialization)
Per the reasons above, anyone who is interested in making traits `const` in the standard library are **strongly encouraged** to reach out to us on the [Zulip channel](https://rust-lang.zulipchat.com/#narrow/channel/419616-t-compiler.2Fproject-const-traits) before proceeding with the work.
cc ``@rust-lang/project-const-traits``
I believe there is prior approval from libs that we can experiment, so
r? project-const-traits
[AIX] Add option -X32_64 to the "strip" command
The AIX `strip` utility requires option `-X` to specify the object mode. This patch adds the `-X32_64` option to the `strip` command so that it can handle both 32-bit and 64-bit objects. The parameter `option` of function `strip_symbols_with_external_utility`, previously a single string, has been changed to `options`, an array of string slices, to accommodate multiple `strip` options.
Re-delay a resolve `bug` related to `Self`-ctor in patterns
For the code pattern reported in <https://github.com/rust-lang/rust/issues/133272>,
```rs
impl Foo {
fn fun() {
let S { ref Self } = todo!();
}
}
```
<https://github.com/rust-lang/rust/pull/121208> converted this to a `span_bug` from a `span_delayed_bug` because this specific self-ctor code pattern lacked test coverage. It turns out this can be hit but we just lacked test coverage, so change it back to a `span_delayed_bug` and add a targeted test case.
Follow-up to #121208, cc ``@nnethercote`` (very good exercise to expose our test coverage gaps).
Fixes#133272.
Allow disabling ASan instrumentation for globals
AddressSanitizer adds instrumentation to global variables unless the [`no_sanitize_address`](https://llvm.org/docs/LangRef.html#global-attributes) attribute is set on them.
This commit extends the existing `#[no_sanitize(address)]` attribute to set this; previously it only had the desired effect on functions.
(cc https://github.com/rust-lang/rust/issues/39699)
Rollup of 8 pull requests
Successful merges:
- #132090 (Stop being so bail-y in candidate assembly)
- #132658 (Detect const in pattern with typo)
- #132911 (Pretty print async fn sugar in opaques and trait bounds)
- #133102 (aarch64 softfloat target: always pass floats in int registers)
- #133159 (Don't allow `-Zunstable-options` to take a value )
- #133208 (generate-copyright: Now generates a library file too.)
- #133215 (Fix missing submodule in `./x vendor`)
- #133264 (implement OsString::truncate)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't allow `-Zunstable-options` to take a value
Passing an explicit boolean value (`-Zunstable-options=on`, `off` etc.) sometimes appears to work, but actually puts the compiler into an unintended state where unstable _options_ are still forbidden, but unstable values of _some_ stable options are allowed.
This is a result of `-Zunstable-options` being checked in multiple different places, in slightly different ways. Fixing the checks in `config::nightly_options` to understand boolean values would be non-trivial, so for now it's easier to make things consistent by forbidding values in the `-Z` parser.
---
There were a few uses of this in tests, which happened to work because they were tests of unstable values.
aarch64 softfloat target: always pass floats in int registers
This is a part of https://github.com/rust-lang/rust/issues/131058: on softfloat aarch64 targets, the float registers may be unavailable. And yet, LLVM will happily use them to pass float types if the corresponding target features are enabled. That's a problem as it means enabling/disabling `neon` instructions can change the ABI.
Other targets have a `soft-float` target feature that forces the use of the soft-float ABI no matter whether float registers are enabled or not; aarch64 has nothing like that.
So we follow the aarch64 [softfloat ABI](https://github.com/rust-lang/rust/issues/131058#issuecomment-2385027423) and treat floats like integers for `extern "C"` functions. For the "Rust" ABI, we do the same for scalars, and then just do something reasonable for ScalarPair that avoids the pointer indirection.
Cc ```@workingjubilee```
Detect const in pattern with typo
When writing a constant name incorrectly in a pattern, the pattern will be identified as a new binding. We look for consts in the current crate, consts that where imported in the current crate and for local `let` bindings in case someone got them confused with `const`s.
```
error: unreachable pattern
--> $DIR/const-with-typo-in-pattern-binding.rs:30:9
|
LL | GOOOD => {}
| ----- matches any value
LL |
LL | _ => {}
| ^ no value can reach this
|
help: you might have meant to pattern match against the value of similarly named constant `GOOD` instead of introducing a new catch-all binding
|
LL | GOOD => {}
| ~~~~
```
Fix#132582.
