[`rustc-rayon v0.5.1`](https://github.com/rust-lang/rustc-rayon/pull/14)
added `indexmap` implementations that will allow `indexmap` to drop its
own "internal-only" implementations.
(This is separate from `indexmap`'s implementation for normal `rayon`.)
Rollup of 10 pull requests
Successful merges:
- #135773 (Clarify WindowsMut (Lending)Iterator)
- #135807 (Implement phantom variance markers)
- #135876 (fix doc for std::sync::mpmc)
- #135988 (Add a workaround for parallel rustc crashing when there are delayed bugs)
- #136037 (Mark all NuttX targets as tier 3 target and support the standard library)
- #136064 (Add a suggestion to cast target_feature fn items to fn pointers.)
- #136082 (Incorporate `iter_nodes` into `graph::DirectedGraph`)
- #136112 (Clean up all dead files inside `tests/ui/`)
- #136114 (Use identifiers more in diagnostics code)
- #136118 (Change `collect_and_partition_mono_items` tuple return type to a struct)
r? `@ghost`
`@rustbot` modify labels: rollup
Trim extra whitespace when suggesting removal of invalid qualifiers when
parsing function pointer type.
Fixes: #133083
Signed-off-by: Tyrone Wu <wudevelops@gmail.com>
Change `collect_and_partition_mono_items` tuple return type to a struct
https://github.com/rust-lang/rust/pull/133429 will add a new field to this tuple, so it seems prudent to turn it into a struct first to avoid confusion about what the tuple elements mean.
Use identifiers more in diagnostics code
This should make the diagnostics code slightly more correct when rendering idents in mixed crate edition situations. Kinda a no-op, but a cleanup regardless.
r? oli-obk or reassign
Incorporate `iter_nodes` into `graph::DirectedGraph`
This helper method iterates over all node IDs in the dense range `0..num_nodes`.
In practice, we have a lot of graph-algorithm code that already assumes that nodes are densely numbered, by using `num_nodes` to allocate per-node indexed data structures. So I don't think this is actually a substantial change to the de-facto semantics of `graph::DirectedGraph`.
---
Resolves a FIXME from #135481.
Add a workaround for parallel rustc crashing when there are delayed bugs
This doesn't fix the root cause of this crash, but at least stops it from happening for the time being.
Workaround for https://github.com/rust-lang/rust/issues/135870
Clang and GCC both return `i128` in xmm0 on windows-msvc and
windows-gnu. Currently, Rust returns the type on the stack. Add a
calling convention adjustment so we also return scalar `i128`s using the
vector ABI, which makes our `i128` compatible with C.
In the future, Clang may change to return `i128` on the stack for its
`-msvc` targets (more at [1]). If this happens, the change here will
need to be adjusted to only affect MinGW.
Link: https://github.com/rust-lang/rust/issues/134288
Put the core unit tests in a separate coretests package
Having standard library tests in the same package as a standard library crate has bad side effects. It causes the test to have a dependency on a locally built standard library crate, while also indirectly depending on it through libtest. Currently this works out fine in the context of rust's build system as both copies are identical, but for example in cg_clif's tests I've found it basically impossible to compile both copies with the exact same compiler flags and thus the two copies would cause lang item conflicts.
This PR moves the tests of libcore to a separate package which doesn't depend on libcore, thus preventing the duplicate crates even when compiler flags don't exactly match between building the sysroot (for libtest) and building the test itself. The rest of the standard library crates do still have this issue however.
This needs more time to bake before we turn it on. Turning it on early risks people silencing the warning indefinitely, before we have the chance to make it less noisy.
Uplift `clippy::double_neg` lint as `double_negations`
Warns about cases like this:
```rust
fn main() {
let x = 1;
let _b = --x; //~ WARN use of a double negation
}
```
The intent is to keep people from thinking that `--x` is a prefix decrement operator. `++x`, `x++` and `x--` are invalid expressions and already have a helpful diagnostic.
I didn't add a machine-applicable suggestion to the lint because it's not entirely clear what the programmer was trying to achieve with the `--x` operation. The code that triggers the lint should always be reviewed manually.
Closes#82987
- `check-pass` test for a MRE of #135020
- fail test for #135138
- switch to `TooGeneric` for checking CMSE fn signatures
- switch to `TooGeneric` for compute `SizeSkeleton` (for transmute)
- fix broken tests
Consistently use the highest bit of vector masks when converting to i1 vectors
This improves the codegen for vector `select`, `gather`, `scatter` and boolean reduction intrinsics and fixesrust-lang/portable-simd#316.
The current behavior of most mask operations during llvm codegen is to truncate the mask vector to <N x i1>, telling llvm to use the least significat bit. The exception is the `simd_bitmask` intrinsics, which already used the most signifiant bit.
Since sse/avx instructions are defined to use the most significant bit, truncating means that llvm has to insert a left shift to move the bit into the most significant position, before the mask can actually be used.
Similarly on aarch64, mask operations like blend work bit by bit, repeating the least significant bit across the whole lane involves shifting it into the sign position and then comparing against zero.
By shifting before truncating to <N x i1>, we tell llvm that we only consider the most significant bit, removing the need for additional shift instructions in the assembly.
This improves the codegen for vector `select`, `gather`, `scatter` and
boolean reduction intrinsics and fixesrust-lang/portable-simd#316.
The current behavior of most mask operations during llvm codegen is to
truncate the mask vector to <N x i1>, telling llvm to use the least
significat bit. The exception is the `simd_bitmask` intrinsics, which
already used the most signifiant bit.
Since sse/avx instructions are defined to use the most significant bit,
truncating means that llvm has to insert a left shift to move the bit
into the most significant position, before the mask can actually be
used.
Similarly on aarch64, mask operations like blend work bit by bit,
repeating the least significant bit across the whole lane involves
shifting it into the sign position and then comparing against zero.
By shifting before truncating to <N x i1>, we tell llvm that we only
consider the most significant bit, removing the need for additional
shift instructions in the assembly.
Rollup of 7 pull requests
Successful merges:
- #133631 (Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only))
- #134358 (compiler: Set `target_abi = "ilp32e"` on all riscv32e targets)
- #135812 (Fix GDB `OsString` provider on Windows )
- #135842 (TRPL: more backward-compatible Edition changes)
- #135946 (Remove extra whitespace from rustdoc breadcrumbs for copypasting)
- #135953 (ci.py: check the return code in `run-local`)
- #136019 (Add an `unchecked_div` alias to the `Div<NonZero<_>>` impls)
r? `@ghost`
`@rustbot` modify labels: rollup
Get rid of `mir::Const::from_ty_const`
This function is strange, because it turns valtrees into `mir::Const::Value`, but the rest of the const variants stay as type system consts.
All of the callsites except for one in `instsimplify` (array length simplification of `ptr_metadata` call) just go through the valtree arm of the function, so it's easier to just create a `mir::Const` directly for those.
For the instsimplify case, if we have a type system const we should *keep* having a type system const, rather than turning it into a `mir::Const::Value`; it doesn't really matter in practice, though, bc `usize` has no padding, but it feels more principled.
compiler: Set `target_abi = "ilp32e"` on all riscv32e targets
This allows compile-time configuration based on this. In the near future we should do this across all RISCV targets, probably, but this cfg is essential for building software usable on these targets, and they are tier 3 so it seems less of a concern to tweak their definition thusly.
Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only)
Changes of this pull request:
1. Refactor code for qnx nto targets to share more code in file `nto_qnx.rs`
1. Add support for an additional network stack on nto qnx 7.1.
QNX 7.1 supports two network stacks:
1. `io-pkt`, which is default
2. `io-sock`, which is optional on 7.1 but default in QNX 8.0
As one can see in the [io-sock migration notes](https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.io_sock/topic/migrate_app.html), this changes the libc API in a way similar to e.g. linux-gnu vs. linux-musl.
This change adds a new target which has a different value for `target_env`, so that e.g. libc can distinguish between both APIs.
2. Add initial support for QNX 8.0, thanks to AkhilTThomas. As it turned out, the problem with forking many processes still exists in QNX 8.0. Because if this, we are now using it for any QNX version (i.e. not check for `target_env` anymore).
Account for mutable borrow in argument suggestion
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:21:5
|
LL | object = &mut object2;
| ^^^^^^
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object3(object: &mut Object) {
LL |
LL | let object2 = Object;
LL ~ *object = object2;
|
```
instead of
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:21:5
|
LL | object = &mut object2;
| ^^^^^^
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object3(object: &mut mut Object) {
LL |
LL | let object2 = Object;
LL ~ *object = object2;
|
```
Fix#136028.
Expand polonius MIR dump
This PR starts expanding the polonius MIR:
- switches to an HTML file, to show graphs in the same document as the MIR dump, share them more easily since it's a single file that can be hosted as a gist, and also to allow for interactivity in the near future.
- adds the regular NLL MIR + polonius constraints
- embeds a mermaid version of the CFG, similar to the graphviz one, but that needs a smaller js than `dot`'s emscripten js from graphvizonline
[Here's an example](https://gistpreview.github.io/?0c18f2a59b5e24ac0f96447aa34ffe00) of how it looks.
---
In future PRs: mermaid graphs of the NLL region graph, of the NLL SCCs, of the polonius localized outlives constraints, and the interactive polonius MIR dump.
r? ```@matthewjasper```
use `PassMode::Direct` for vector types on `s390x`
closes https://github.com/rust-lang/rust/issues/135744
tracking issue: https://github.com/rust-lang/rust/issues/130869
Previously, all vector types were type erased to `Ni8`, now we pass non-wrapped vector types directly. That skips emitting a bunch of casting logic in rustc, that LLVM then has to clean up. The initial LLVM IR is also a bit more readable.
This calling convention is tested extensively in `tests/assembly/s390x-vector-abi.rs`, showing that this change has no impact on the ABI in practice.
r? ````@taiki-e````
Make the wasm_c_abi future compat warning a hard error
This is the next step in getting rid of the broken C abi for wasm32-unknown-unknown.
The lint was made deny-by-default in https://github.com/rust-lang/rust/pull/129534 3 months ago. This still keeps the `-Zwasm-c-abi` flag set to `legacy` by default. It will be flipped in a future PR.
cc https://github.com/rust-lang/rust/issues/122532
This assumes that the set of valid node IDs is exactly `0..num_nodes`.
In practice, we have a lot of graph-algorithm code that already assumes that
nodes are densely numbered, by using `num_nodes` to allocate per-node indexed
data structures.
Improve check-cfg expected names diagnostic
This PR improves the check-cfg `allow-same-level` test by ~~normalizing it's output and by~~ adding more context to the test.
It also filters the well known cfgs from the `expected names are` note, as to reduce the size of the diagnostic. Users can still find the full list on the [rustc book](https://doc.rust-lang.org/nightly/rustc/check-cfg.html#well-known-names-and-values), which is reinforced for Cargo users by adding a note in the Cargo check-cfg specific section.
Fixes https://github.com/rust-lang/rust/issues/135995
r? `@jieyouxu`
- Don't show environment variables. Seeing PATH is almost never useful, and it can be extremely long.
- For .rlibs in the sysroot, replace crate hashes with a `"-*"` string. This will expand to the full crate name when pasted into the shell.
- Move `.rlib` to outside the glob.
- Abbreviate the sysroot path to `<sysroot>` wherever it appears in the arguments.
This also adds an example of the linker output as a run-make test. Currently it only runs on x86_64-unknown-linux-gnu, because each platform has its own linker arguments. So that it's stable across machines, pass BUILD_ROOT as an argument through compiletest through to run-make tests.
- Only use linker-flavor=gnu-cc if we're actually going to compare the output. It doesn't exist on MacOS.
Reword resolve errors caused by likely missing crate in dep tree
Reword label and add `help`:
```
error[E0432]: unresolved import `some_novel_crate`
--> f704.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
|
= help: if you wanted to use a crate named `some_novel_crate`, use `cargo add some_novel_crate` to add it to your `Cargo.toml`
```
Fix#133137.
for cases where we want to dump the MIR to a given writer instead of a
new file as the default does.
this will be used when dumping the MIR to a buffer to process
differently, e.g. post-process to escape for an HTML dump.
Skip suggestions in `derive`d code
Do not suggest
```
help: use parentheses to call these
|
5 | (callback: Rc<dyn Fn()>)(),
| + +++
```
Skip all "call function for this binop" suggestions when in a derive context.
Fix#135989.
Use short ty string for move errors
```
error[E0382]: use of moved value: `x`
--> bay.rs:14:14
|
12 | fn foo(x: D) {
| - move occurs because `x` has type `(((..., ..., ..., ...), ..., ..., ...), ..., ..., ...)`, which does not implement the `Copy` trait
13 | let _a = x;
| - value moved here
14 | let _b = x; //~ ERROR use of moved value
| ^ value used here after move
|
= note: the full type name has been written to 'bay.long-type-14349227078439097973.txt'
= note: consider using `--verbose` to print the full type name to the console
help: consider cloning the value if the performance cost is acceptable
|
13 | let _a = x.clone();
| ++++++++
```
Address 4th case in #135919.
Properly report error when object type param default references self
I accidentally broke this error for cases where a type parameter references `Self` via a projection (i.e. `trait Foo<Arg = Self::Bar> {}`). This PR fixes that, and also makes the error a bit easier to understand.
Fixes#135918
Add `#[optimize(none)]`
cc #54882
This extends the `optimize` attribute to add `none`, which corresponds to the LLVM `OptimizeNone` attribute.
Not sure if an MCP is required for this, happy to file one if so.
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:21:5
|
LL | object = &mut object2;
| ^^^^^^
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object3(object: &mut Object) {
LL |
LL | let object2 = Object;
LL ~ *object = object2;
|
```
instead of
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:21:5
|
LL | object = &mut object2;
| ^^^^^^
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object3(object: &mut mut Object) {
LL |
LL | let object2 = Object;
LL ~ *object = object2;
|
```
Fix#136028.
Don't drop types with no drop glue when building drops for tailcalls
this is required as otherwise drops of `&mut` refs count as a usage of a
'two-phase temporary' causing an ICE.
fixes#128097
The underlying issue is that the current code generates drops for `&mut` which are later counted as a second use of a two-phase temporary:
`bat t.rs -p`
```rust
#![expect(incomplete_features)]
#![feature(explicit_tail_calls)]
fn f(x: &mut ()) {
let _y = String::new();
become f(x);
}
fn main() {}
```
`rustc t.rs -Zdump_mir=f`
```text
error: internal compiler error: compiler/rustc_borrowck/src/borrow_set.rs:298:17: found two uses for 2-phase borrow temporary _4: bb2[1] and bb3[0]
--> t.rs:6:5
|
6 | become f(x);
| ^^^^^^^^^^^
thread 'rustc' panicked at compiler/rustc_borrowck/src/borrow_set.rs:298:17:
Box<dyn Any>
stack backtrace:
[REDACTED]
error: aborting due to 1 previous error
```
`bat ./mir_dump/t.f.-------.renumber.0.mir -p -lrust`
```rust
// MIR for `f` 0 renumber
fn f(_1: &mut ()) -> () {
debug x => _1;
let mut _0: ();
let mut _2: !;
let _3: std::string::String;
let mut _4: &mut ();
scope 1 {
debug _y => _3;
}
bb0: {
StorageLive(_3);
_3 = String::new() -> [return: bb1, unwind: bb4];
}
bb1: {
FakeRead(ForLet(None), _3);
StorageLive(_4);
_4 = &mut (*_1);
drop(_3) -> [return: bb2, unwind: bb3];
}
bb2: {
StorageDead(_3);
tailcall f(Spanned { node: move _4, span: t.rs:6:14: 6:15 (#0) });
}
bb3 (cleanup): {
drop(_4) -> [return: bb4, unwind terminate(cleanup)];
}
bb4 (cleanup): {
resume;
}
}
```
Note how `_4 is moved into the tail call in `bb2` and dropped in `bb3`.
This PR adds a check that the locals we drop need dropping.
r? `@oli-obk` (feel free to reassign, I'm not sure who would be a good reviewer, but thought you might have an idea)
cc `@beepster4096,` since you wrote the original drop implementation.
Use short type string in E0308 secondary span label
We were previously printing the full type on the "this expression has type" label.
```
error[E0308]: mismatched types
--> $DIR/secondary-label-with-long-type.rs:8:9
|
LL | let () = x;
| ^^ - this expression has type `((..., ..., ..., ...), ..., ..., ...)`
| |
| expected `((..., ..., ..., ...), ..., ..., ...)`, found `()`
|
= note: expected tuple `((..., ..., ..., ...), ..., ..., ...)`
found unit type `()`
= note: the full type name has been written to '$TEST_BUILD_DIR/diagnostic-width/secondary-label-with-long-type/secondary-label-with-long-type.long-type-3987761834644699448.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Reported in a comment of #135919.
Separate Builder methods from tcx
As part of the autodiff upstreaming we noticed, that it would be nice to have various builder methods available without the TypeContext, which prevents the normal CodegenCx to be passed around between threads.
We introduce a SimpleCx which just owns the llvm module and llvm context, to encapsulate them.
The previous CodegenCx now implements deref and forwards access to the llvm module or context to it's SimpleCx sub-struct. This gives us a bit more flexibility, because now we can pass (or construct) the SimpleCx in locations where we don't have enough information to construct a CodegenCx, or are not able to pass it around due to the tcx lifetimes (and it not implementing send/sync).
This also introduces an SBuilder, similar to the SimpleCx. The SBuilder uses a SimpleCx, whereas the existing Builder uses the larger CodegenCx. I will push updates to make implementations generic (where possible) to be implemented once and work for either of the two. I'll also clean up the leftover code.
`call` is a bit tricky, because it requires a tcx, I probably need to duplicate it after all.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
Do not suggest
```
help: use parentheses to call these
|
5 | (callback: Rc<dyn Fn()>)(),
| + +++
```
Skip all "call function for this binop" suggestions when in a derive context.
Fix#135989.
```
error[E0382]: use of moved value: `x`
--> bay.rs:14:14
|
12 | fn foo(x: D) {
| - move occurs because `x` has type `(((..., ..., ..., ...), ..., ..., ...), ..., ..., ...)`, which does not implement the `Copy` trait
13 | let _a = x;
| - value moved here
14 | let _b = x; //~ ERROR use of moved value
| ^ value used here after move
|
= note: the full type name has been written to 'bay.long-type-14349227078439097973.txt'
= note: consider using `--verbose` to print the full type name to the console
help: consider cloning the value if the performance cost is acceptable
|
13 | let _a = x.clone();
| ++++++++
```
These cannot be silenced with a CLI flag, and are not useful to warn
about. They can still be viewed for debugging purposes using
`RUSTC_LOG=rustc_codegen_ssa:🔗:back`.
coverage: Prepare for upcoming changes to counter creation
This is a collection of smaller changes to coverage instrumentation code that have been extracted from a larger PR that I'm still working on, in order to hopefully make review easier.
Each individual change should hopefully be mostly self-explanatory. One of the big goals of the upcoming PR will be to defer certain parts of counter-creation until codegen, via the query system, so that ends up being a recurring theme in these changes. Several of the changes are follow-ups to #135481.
There should be no observable change in compiler output.
Forbid usage of `hir` `Infer` const/ty variants in ambiguous contexts
The feature `generic_arg_infer` allows providing `_` as an argument to const generics in order to infer them. This introduces a syntactic ambiguity as to whether generic arguments are type or const arguments. In order to get around this we introduced a fourth `GenericArg` variant, `Infer` used to represent `_` as an argument to generic parameters when we don't know if its a type or a const argument.
This made hir visitors that care about `TyKind::Infer` or `ConstArgKind::Infer` very error prone as checking for `TyKind::Infer`s in `visit_ty` would find *some* type infer arguments but not *all* of them as they would sometimes be lowered to `GenericArg::Infer` instead.
Additionally the `visit_infer` method would previously only visit `GenericArg::Infer` not *all* infers (e.g. `TyKind::Infer`), this made it very easy to override `visit_infer` and expect it to visit all infers when in reality it would only visit *some* infers.
---
This PR aims to fix those issues by making the `TyKind` and `ConstArgKind` types generic over whether the infer types/consts are represented by `Ty/ConstArgKind::Infer` or out of line (e.g. by a `GenericArg::Infer` or accessible by overiding `visit_infer`). We then make HIR Visitors convert all const args and types to the versions where infer vars are stored out of line and call `visit_infer` in cases where a `Ty`/`Const` would previously have had a `Ty/ConstArgKind::Infer` variant:
API Summary
```rust
enum AmbigArg {}
enum Ty/ConstArgKind<Unambig = ()> {
...
Infer(Unambig),
}
impl Ty/ConstArg {
fn try_as_ambig_ty/ct(self) -> Option<Ty/ConstArg<AmbigArg>>;
}
impl Ty/ConstArg<AmbigArg> {
fn as_unambig_ty/ct(self) -> Ty/ConstArg;
}
enum InferKind {
Ty(Ty),
Const(ConstArg),
Ambig(InferArg),
}
trait Visitor {
...
fn visit_ty/const_arg(&mut self, Ty/ConstArg<AmbigArg>) -> Self::Result;
fn visit_infer(&mut self, id: HirId, sp: Span, kind: InferKind) -> Self::Result;
}
// blanket impl'd, not meant to be overriden
trait VisitorExt {
fn visit_ty/const_arg_unambig(&mut self, Ty/ConstArg) -> Self::Result;
}
fn walk_unambig_ty/const_arg(&mut V, Ty/ConstArg) -> Self::Result;
fn walk_ty/const_arg(&mut V, Ty/ConstArg<AmbigArg>) -> Self::Result;
```
The end result is that `visit_infer` visits *all* infer args and is also the *only* way to visit an infer arg, `visit_ty` and `visit_const_arg` can now no longer encounter a `Ty/ConstArgKind::Infer`. Representing this in the type system means that it is now very difficult to mess things up, either accessing `TyKind::Infer` "just works" and you won't miss *some* type infers- or it doesn't work and you have to look at `visit_infer` or some `GenericArg::Infer` which forces you to think about the full complexity involved.
Unfortunately there is no lint right now about explicitly matching on uninhabited variants, I can't find the context for why this is the case 🤷♀️
I'm not convinced the framing of un/ambig ty/consts is necessarily the right one but I'm not sure what would be better. I somewhat like calling them full/partial types based on the fact that `Ty<Partial>`/`Ty<Full>` directly specifies how many of the type kinds are actually represented compared to `Ty<Ambig>` which which leaves that to the reader to figure out based on the logical consequences of it the type being in an ambiguous position.
---
tool changes have been modified in their own commits for easier reviewing by anyone getting cc'd from subtree changes. I also attempted to split out "bug fixes arising from the refactoring" into their own commit so they arent lumped in with a big general refactor commit
Fixes#112110
Rollup of 8 pull requests
Successful merges:
- #133605 (Add extensive set of drop order tests)
- #135489 (remove pointless allowed_through_unstable_modules on TryFromSliceError)
- #135757 (Add NuttX support for AArch64 and ARMv7-A targets)
- #135799 (rustdoc-json: Rename `Path::name` to `path`, and give it the path again.)
- #135865 (For E0223, suggest associated functions that are similar to the path, even if the base type has multiple inherent impl blocks.)
- #135890 (Implement `VecDeque::pop_front_if` & `VecDeque::pop_back_if`)
- #135914 (Remove usages of `QueryNormalizer` in the compiler)
- #135936 (fix reify-intrinsic test)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove usages of `QueryNormalizer` in the compiler
I want to get rid of the `QueryNormalizer`, possibly changing it to be special cased just for normalizing erasing regions, or perhaps adapting `normalize_erasing_regions` to use the assoc type normalizer if caching is sufficient and removing it altogther.
This removes the last two usages of `.query_normalize` in the *compiler*. There are a few usages left in rustdoc and clippy, which exist only because the query normalizer is more resilient to errors and non-well-formed alias types. I will remove those next.
r? lcnr or reassign
For E0223, suggest associated functions that are similar to the path, even if the base type has multiple inherent impl blocks.
Currently, the "help: there is an associated function with a similar name `from_utf8`" suggestion for `String::from::utf8` is only given if `String` has exactly one inherent `impl` item. This PR makes the suggestion be emitted even if the base type has multiple inherent `impl` items.
Example:
```rust
struct Foo;
impl Foo {
fn bar_baz() {}
}
impl Foo {} // load-bearing
fn main() {
Foo::bar::baz;
}
```
Nightly/stable output:
```rust
error[E0223]: ambiguous associated type
--> f.rs:7:5
|
7 | Foo::bar::baz;
| ^^^^^^^^
|
help: if there were a trait named `Example` with associated type `bar` implemented for `Foo`, you could use the fully-qualified path
|
7 | <Foo as Example>::bar::baz;
| ~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0223`.
```
Output with this PR, or without the load-bearing empty impl on nightly/stable:
```rust
error[E0223]: ambiguous associated type
--> f.rs:7:5
|
7 | Foo::bar::baz;
| ^^^^^^^^
|
help: there is an associated function with a similar name: `bar_baz`
|
7 | Foo::bar_baz;
| ~~~~~~~
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0223`.
```
Ideally, this suggestion would also work for non-ADT types like ~~`str::char::indices`~~ (edit: latest commit makes this work with primitives) or `<dyn Any>::downcast::mut_unchecked`, but that seemed to be a harder change.
`@rustbot` label +A-diagnostics
Add NuttX support for AArch64 and ARMv7-A targets
This patch adds tier 3 support for AArch64 and ARMv7-A targets in NuttX, including:
- AArch64 target: aarch64-unknown-nuttx
- ARMv7-A target: armv7a-nuttx-eabi, armv7a-nuttx-eabihf
- Thumbv7-A target: thumbv7a-nuttx-eabi, thumbv7a-nuttx-eabihf
By removing all methods from this struct and treating it as a collection of
data fields, we make it easier for a future PR to store that data in a query
result, without having to move all of its methods into `rustc_middle`.
This dedicated type seemed like a good idea at the time, but if we want to
store this information in a query result then a plainer data type is more
convenient.
Using `SmallVec` here was fine when it was a module-private detail, but if we
want to pass these terms across query boundaries then it's not worth the extra
hassle.
Replacing a method call with direct field access is slightly simpler.
Using the name `counter_terms` is more consistent with other code that tries to
maintain a distinction between (physical) "counters" and "expressions".
This reflects the fact that we can't compute meaningful info for a function
that wasn't instrumented and therefore doesn't have `function_coverage_info`.
These types are unlikely to ever contain type information in the foreseeable
future, so excluding them from TypeFoldable/TypeVisitable avoids some unhelpful
derive boilerplate.
Rollup of 7 pull requests
Successful merges:
- #135366 (Enable `unreachable_pub` lint in `test` and `proc_macro` crates)
- #135638 (Make it possible to build GCC on CI)
- #135648 (support wasm inline assembly in `naked_asm!`)
- #135827 (CI: free disk with in-tree script instead of GitHub Action)
- #135855 (Only assert the `Parser` size on specific arches)
- #135878 (ci: use 8 core arm runner for dist-aarch64-linux)
- #135905 (Enable kernel sanitizers for aarch64-unknown-none-softfloat)
r? `@ghost`
`@rustbot` modify labels: rollup
```
error[E0432]: unresolved import `some_novel_crate`
--> file.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
```
On resolve errors where there might be a missing crate, mention `cargo add foo`:
```
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `nope`
--> $DIR/conflicting-impl-with-err.rs:4:11
|
LL | impl From<nope::Thing> for Error {
| ^^^^ use of unresolved module or unlinked crate `nope`
|
= help: if you wanted to use a crate named `nope`, use `cargo add nope` to add it to your `Cargo.toml`
```
We were previously printing the full type on the "this expression has type" label.
```
error[E0308]: mismatched types
--> $DIR/secondary-label-with-long-type.rs:8:9
|
LL | let () = x;
| ^^ - this expression has type `((..., ..., ..., ...), ..., ..., ...)`
| |
| expected `((..., ..., ..., ...), ..., ..., ...)`, found `()`
|
= note: expected tuple `((..., ..., ..., ...), ..., ..., ...)`
found unit type `()`
= note: the full type name has been written to '$TEST_BUILD_DIR/diagnostic-width/secondary-label-with-long-type/secondary-label-with-long-type.long-type-3987761834644699448.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Reported in a comment of #135919.
Skip `if-let-rescope` lint unless requested by migration
Tracked by #124085
Related to https://github.com/rust-lang/rust/pull/131984#issuecomment-2448329667
Given that `if-let-rescope` is a lint to be enabled globally by an edition migration, there is no point in extracting the precise lint level on the HIR expression. This mitigates the performance regression discovered by the earlier perf-run.
cc `@Kobzol` `@rylev` `@traviscross` I propose a `rust-timer` run to measure how much performance that we can recover from the mitigation. 🙇
Enable kernel sanitizers for aarch64-unknown-none-softfloat
We want kernels to be able to use this bare metal target, so let's enable the sanitizers that kernels want to use.
cc ```@rcvalle``` ```@ojeda``` ```@maurer```
Only assert the `Parser` size on specific arches
The size of this struct depends on the alignment of `u128`, for example
powerpc64le and s390x have align-8 and end up with only 280 bytes. Our
64-bit tier-1 arches are the same though, so let's just assert on those.
r? nnethercote
support wasm inline assembly in `naked_asm!`
fixes https://github.com/rust-lang/rust/issues/135518
Webassembly was overlooked previously, but now `naked_asm!` and `#[naked]` functions work on the webassembly targets.
Or, they almost do right now. I guess this is no surprise, but the `wasm32-unknown-unknown` target causes me some trouble. I'll add some inline comments with more details.
r? ```````@bjorn3```````
cc ```````@daxpedda,``````` ```````@tgross35```````
Allow `arena_cache` queries to return `Option<&'tcx T>`
Currently, `arena_cache` queries always have to return `&'tcx T`[^deref]. This means that if an arena-cached query wants to return an optional value, it has to return `&'tcx Option<T>`, which has a few negative consequences:
- It goes against normal Rust style, where `Option<&T>` is preferred over `&Option<T>`.
- Callers that actually want an `Option<&T>` have to manually call `.as_ref()` on the query result.
- When the query result is `None`, a full-sized `Option<T>` still needs to be stored in the arena.
This PR solves that problem by introducing a helper trait `ArenaCached` that is implemented for both `&T` and `Option<&T>`, and takes care of bridging between the provided type, the arena-allocated type, and the declared query return type.
---
To demonstrate that this works, I have converted the two existing arena-cached queries that currently return `&Option<T>`: `mir_coroutine_witnesses` and `diagnostic_hir_wf_check`. Only the query declarations need to be modified; existing providers and callers continue to work with the new query return type.
(My real goal is to apply this to `coverage_ids_info`, which will return Option as of #135873, but that PR hasn't landed yet.)
[^deref]: Technically they could return other types that implement `Deref`, but it's hard to imagine this working well with anything other than `&T`.
rustc_codegen_llvm: remove outdated asm-to-obj codegen note
Remove comment about missing integrated assembler handling, which was removed in commit 02840ca.
Get rid of RunCompiler
The various `set_*` methods that have been removed can be replaced by setting the respective fields in the `Callbacks::config` implementation. `set_using_internal_features` was often forgotten and it's equivalent is now done automatically.
handle global trait bounds defining assoc types
This also fixes the compare-mode for
- tests/ui/coherence/coherent-due-to-fulfill.rs
- tests/ui/codegen/mono-impossible-2.rs
- tests/ui/trivial-bounds/trivial-bounds-inconsistent-projection.rs
- tests/ui/nll/issue-61320-normalize.rs
I first considered the alternative to always prefer where-bounds during normalization, regardless of how the trait goal has been proven by changing `fn merge_candidates` instead. ecda83b30f/compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs (L785)
This approach is more restrictive than behavior of the old solver to avoid mismatches between trait and normalization goals. This may be breaking in case the where-bound adds unnecessary region constraints and we currently don't ever try to normalize an associated type. I would like to detect these cases and change the approach to exactly match the old solver if required. I want to minimize cases where attempting to normalize in more places causes code to break.
r? `@compiler-errors`
Add missing check for async body when suggesting await on futures.
Currently the compiler suggests adding `.await` to resolve some type conflicts without checking if the conflict happens in an async context. This can lead to the compiler suggesting `.await` in function signatures where it is invalid. Example:
```rs
trait A {
fn a() -> impl Future<Output = ()>;
}
struct B;
impl A for B {
fn a() -> impl Future<Output = impl Future<Output = ()>> {
async { async { () } }
}
}
```
```
error[E0271]: expected `impl Future<Output = impl Future<Output = ()>>` to be a future that resolves to `()`, but it resolves to `impl Future<Output = ()>`
--> bug.rs:6:15
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found future
|
note: calling an async function returns a future
--> bug.rs:6:15
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `A::{synthetic#0}`
--> bug.rs:2:27
|
2 | fn a() -> impl Future<Output = ()>;
| ^^^^^^^^^^^ required by this bound in `A::{synthetic#0}`
help: consider `await`ing on the `Future`
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>>.await {
| ++++++
```
The documentation of suggest_await_on_expect_found (`compiler/rustc_trait_selection/src/error_reporting/infer/suggest.rs:156`) even mentions such a check but does not actually implement it.
This PR adds that check to ensure `.await` is only suggested within async blocks.
There were 3 unit tests whose expected output needed to be changed because they had the suggestion outside of async. One of them (`tests/ui/async-await/dont-suggest-missing-await.rs`) actually tests that exact problem but expects it to be present.
Thanks to `@llenck` for initially noticing the bug and helping with fixing it
Update windows-gnu targets to set `DebuginfoKind::DWARF`
These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo.
This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers.
cc ````@mati865```` since you mentioned this in #135739
cc ````@davidtwco```` for split-dwarf
[AIX] Lint on structs that have a different alignment in AIX's C ABI
This PR adds a linting diagnostic on AIX for repr(C) structs that are required to follow
the power alignment rule. A repr(C) struct needs to follow the power alignment rule if
the struct:
- Has a floating-point data type (greater than 4-bytes) as its first member, or
- The first member of the struct is an aggregate, whose recursively first member is a
floating-point data type (greater than 4-bytes).
The power alignment rule for eligible structs is currently unimplemented, so a linting
diagnostic is produced when such a struct is encountered.
Always lower to `GenericArg::Infer`
Update `PlaceholderCollector`
Update closure lifetime binder infer var visitor
Fallback visitor handle ambig infer args
Ensure type infer args have their type recorded
Misc. `rustc_resolve` cleanups
Hopefully this PR should make `rustc_resolve` a bit cleaner.
Each commit here stands on its own. I tried to only include changes that are easy to review, and are a clear improvement. (but I'll be happy to revert any changes that turn out to be more controversial than I'd thought)
Best viewed with whitespace ignored 😁 (especially [these two commits](a93616acf3..ae87d005bc?diff=unified&w=1))
Detect missing fields with default values and suggest `..`
When a struct ctor use has missing fields, if all those missing fields have defaults, suggest `..`:
```
error[E0063]: missing fields `field1` and `field2` in initializer of `S`
--> $DIR/non-exhaustive-ctor.rs:16:13
|
LL | let _ = S { field: () };
| ^ missing `field1` and `field2`
|
help: all remaining fields have default values, you can use those values with `..`
|
LL | let _ = S { field: (), .. };
| ++++
```
Properly note when query stack is being cut off
cc #70953
also, i'm not certain whether we should even limit this at all. i don't see the problem with printing the full query stack, apparently it was limited b/c we used to ICE? but we're already printing the full stack to disk since #108714.
r? oli-obk
Point at invalid utf-8 span on user's source code
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
--> $DIR/not-utf8-2.rs:6:5
|
LL | include!("not-utf8-bin-file.rs");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: byte `193` is not valid utf-8
--> $DIR/not-utf8-bin-file.rs:2:14
|
LL | let _ = "�|�␂!5�cc␕␂��";
| ^
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```
When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.
Fix#76869.
Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block
Fixes#133117 , and close fixes#133063 , fixes#130779
In order to fix ICE-133117, at first I needed to tackle to ICE-133063 (this fixed 130779 as well).
### ICE-133063 and ICE-130779
This ICE is caused by those steps:
1. An arm has or-pattern, and all of the sub-candidates are never-pattern
2. In that case, all sub-candidates are removed in remove_never_subcandidates(). So the arm (candidate) has no sub-candidate.
3. In the current implementation, if there is no sub-candidate, the function assigns `pre_binding_block` into the candidate ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L2002-L2004)). However, otherwise_block should be assigned to the candidate as well, because the otherwise_block is unwrapped in multiple place (like in lower_match_tree()). As a result, it causes the panic.
I simply added the same block as pre_binding_block into otherwise_block, but I'm wondering if there is a better block to assign to otherwise_block (is it ok to assign the same block into pre_binding and otherwise?)
### ICE-133117
This is caused by those steps:
1. There are two arms, both are or-pattern and each has one match-pair (in the test code, both are `(!|!)`), and the second arm has a guard.
2. In match_candidate() for the first arm, it expands the second arm’s sub-candidates as well ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1800-L1805)). As a result, the root candidate of the second arm is not evaluated/modified in match_candidate(). So a false_edge_start_block is not assigned to the candidate.
3. merge_trivial_subcandidates() is called against the candidate for the second arm. It just returns immediately because the candidate has a guard. So a flase_edge_start_block is not assigned to the candidate also in this function.
4. remove_never_subcandidates() is called against the candidate. Since all sub-candidates are never-pattern. they are removed.
5. In lower_match_tree(), since there is no sub-candidate for the candidate, the candidate itself is evaluated in visit_leave_rev ([here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/builder/matches/mod.rs#L1532)). Because the candidate has no false_edge_start_block, it causes the panic.
So I modified the order of if blocks in merge_trivial_subcandidates() to assign a false_edge_start_block if the candidate doesn't have.
Enforce that all spans are lowered in ast lowering
This should ensure that incremental is used as extensively as possible. It's only a debug assertion, and only enabled when incremental is enabled (as we only lower spans to relative spans then).
Don't pick `T: FnPtr` nested goals as the leaf goal in diagnostics for new solver
r? `@lcnr`
See `tests/ui/traits/next-solver/diagnostics/dont-pick-fnptr-bound-as-leaf.rs` for a minimized example of what code this affects the diagnostics off. The output of running nightly `-Znext-solver` on that test is the following:
```
error[E0277]: the trait bound `Foo: Trait` is not satisfied
--> src/lib.rs:14:20
|
14 | requires_trait(Foo);
| -------------- ^^^ the trait `FnPtr` is not implemented for `Foo`
| |
| required by a bound introduced by this call
|
note: required for `Foo` to implement `Trait`
--> src/lib.rs:7:16
|
7 | impl<T: FnPtr> Trait for T {}
| ----- ^^^^^ ^
| |
| unsatisfied trait bound introduced here
note: required by a bound in `requires_trait`
--> src/lib.rs:11:22
|
11 | fn requires_trait<T: Trait>(_: T) {}
| ^^^^^ required by this bound in `requires_trait`
```
Part of rust-lang/trait-system-refactor-initiative#148
Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors
r? `@lcnr`
I added `structurally_normalize_term` so that code that is generic over ty or const can use the structurally normalize helpers. See `tests/ui/traits/next-solver/diagnostics/alias_relate_error_uses_structurally_normalize.rs` for a description of the reason for the (now fixed) ICEs
Make our `DIFlags` match `LLVMDIFlags` in the LLVM-C API
In order to be able to use a mixture of LLVM-C and C++ bindings for debuginfo, our Rust-side `DIFlags` needs to have the same layout as LLVM-C's `LLVMDIFlags`, and we also need to be able to convert it to the `DIFlags` accepted by LLVM's C++ API.
Internally, LLVM converts between the two types with a simple cast. We can't necessarily rely on that always being true, and LLVM doesn't expose a conversion function, so we have two potential options:
- Convert each bit/subvalue individually
- Statically assert that doing a cast is actually fine
As long as both types do remain the same under the hood (which seems likely), the static-assert-and-cast approach is easier and faster. If the static assertions ever start failing against some future version of LLVM, we'll have to switch over to the convert-each-subvalue approach, which is a bit more error-prone.
---
Extracted from #134009, though this PR ended up choosing the static-assert-and-cast approach over the convert-each-subvalue approach.
AIX: use align 8 for byval parameter
On AIX, byval pointer arguments are aligned to 8 bytes based on the 64bit register size. For example, the C callee https://godbolt.org/z/5f4vnG6bh will expect the following argument.
```
ptr nocapture noundef readonly byval(%struct.TwoU64s) align 8 %0
```
This case is captured by `run-make/extern-fn-explicit-align`
Refactor dyn-compatibility error and suggestions
This CL makes a number of small changes to dyn compatibility errors:
- "object safety" has been renamed to "dyn-compatibility" throughout
- "Convert to enum" suggestions are no longer generated when there exists a type-generic impl of the trait or an impl for `dyn OtherTrait`
- Several error messages are reorganized for user readability
Additionally, the dyn compatibility error creation code has been split out into functions.
cc #132713
cc #133267
r? `@compiler-errors`
This CL makes a number of small changes to dyn compatibility errors:
- "object safety" has been renamed to "dyn-compatibility" throughout
- "Convert to enum" suggestions are no longer generated when there
exists a type-generic impl of the trait or an impl for `dyn OtherTrait`
- Several error messages are reorganized for user readability
Additionally, the dyn compatibility error creation code has been
split out into functions.
cc #132713
cc #133267
Properly record metavar spans for other expansions other than TT
This properly records metavar spans for nonterminals other than tokentree. This means that we operations like `span.to(other_span)` work correctly for macros. As you can see, other diagnostics involving metavars have improved as a result.
Fixes#132908
Alternative to #133270
cc `@ehuss`
cc `@petrochenkov`
Update our range `assume`s to the format that LLVM prefers
I found out in https://github.com/llvm/llvm-project/issues/123278#issuecomment-2597440158 that the way I started emitting the `assume`s in #109993 was suboptimal, and as seen in that LLVM issue the way we're doing it -- with two `assume`s sometimes -- can at times lead to CVP/SCCP not realize what's happening because one of them turns into a `ne` instead of conveying a range.
So this updates how it's emitted from
```
assume( x >= LOW );
assume( x <= HIGH );
```
or
```
// (for ranges that wrap the range)
assume( (x <= LOW) | (x >= HIGH) );
```
to
```
assume( (x - LOW) <= (HIGH - LOW) );
```
so that we don't need multiple `icmp`s nor multiple `assume`s for a single value, and both wrappping and non-wrapping ranges emit the same shape.
(And we don't bother emitting the subtraction if `LOW` is zero, since that's trivial for us to check too.)
The candidate shouldn't have false_edge_start_block if it has sub candidates.
In remove_never_subcandidates(), the false_edge_start_block from the first sub candidte is assigned to a value and the value is later used if all sub candidates are removed and candidate doesn't have false_edge_start_block.
In merge_trivial_subcandidates, I leave the if block which assign a false_edge_start_block into the candidate as before I put this commit since compile panics.
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
The size of this struct depends on the alignment of `u128`, for example
powerpc64le and s390x have align-8 and end up with only 280 bytes. Our
64-bit tier-1 arches are the same though, so let's just assert on those.
Rollup of 8 pull requests
Successful merges:
- #132232 (CI: build FreeBSD artifacts on FreeBSD 13.4)
- #135706 (Move `supertrait_def_ids` into the elaborate module like all other fns)
- #135750 (Add an example of using `carrying_mul_add` to write wider multiplication)
- #135793 (Ignore `mermaid.min.js`)
- #135810 (Add Kobzol on vacation)
- #135821 (fix OsString::from_encoded_bytes_unchecked description)
- #135824 (tests: delete `cat-and-grep-sanity-check`)
- #135833 (Add fixme and test for issue #135289)
Failed merges:
- #135816 (Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors)
r? `@ghost`
`@rustbot` modify labels: rollup
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
--> $DIR/not-utf8-2.rs:6:5
|
LL | include!("not-utf8-bin-file.rs");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: `[193]` is not valid utf-8
--> $DIR/not-utf8-bin-file.rs:2:14
|
LL | let _ = "�|�␂!5�cc␕␂��";
| ^
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```
When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.
Fix#76869.
Add fixme and test for issue #135289
This PR:
- adds a test minimizing issue #135289 for PR #135310
- adds a fixme about the suboptimal fix for the ICE
I've verified the test indeed ICEs with 3f2f695d68 reverted.
r? `@estebank`
bump compiler and tools to windows 0.59, bootstrap to 0.57
This bumps compiler and tools to windows 0.59 (temporary dupes version, as `sysinfo` still depend on <= 0.57).
Bootstrap bumps only to 0.57 (the same sysinfo dep).
This additionally resolves my comment https://github.com/rust-lang/rust/pull/130874#issuecomment-2393562071
Will work on it in follow up pr: There still some sus imports for `rustc_driver.dll` like ws2_32 or RoOriginateErrorW, but i will look at them later.
When a struct definition has default field values, and the use struct ctor has missing field, if all those missing fields have defaults suggest `..`:
```
error[E0063]: missing fields `field1` and `field2` in initializer of `S`
--> $DIR/non-exhaustive-ctor.rs:16:13
|
LL | let _ = S { field: () };
| ^ missing `field1` and `field2`
|
help: all remaining fields have defaults, use `..`
|
LL | let _ = S { field: (), .. };
| ++++
```
remove support for the (unstable) #[start] attribute
As explained by `@Noratrieb:`
`#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
- `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
- `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways*
`#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program.
So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
Note that this feature has **not** been RFCed in the first place.
*This comment was posted [in May](https://github.com/rust-lang/rust/issues/29633#issuecomment-2088596042) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.*
Closes https://github.com/rust-lang/rust/issues/29633
try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
Rework dyn trait lowering to stop being so intertwined with trait alias expansion
This PR reworks the trait object lowering code to stop handling trait aliases so funky, and removes the `TraitAliasExpander` in favor of a much simpler design. This refactoring is important for making the code that I'm writing in https://github.com/rust-lang/rust/pull/133397 understandable and easy to maintain, so the diagnostics regressions are IMO inevitable.
In the old trait object lowering code, we used to be a bit sloppy with the lists of traits in their unexpanded and expanded forms. This PR largely rewrites this logic to expand the trait aliases *once* and handle them more responsibly throughout afterwards.
Please review this with whitespace disabled.
r? lcnr
I think the diagnostic could use some work, but it's more helpful than
the alternative. The previous error was misleading, since it ignored the
inherited reference altogether.
The debug assertion ensuring that the pattern mutability cap holds
assumes the presence of Rule 3, so it now checks for that. I
considered going back to only tracking the mutability cap when Rule 3
is present, but since the mutability cap is used in Rule 5's
implementation too, the debug assertion would still need to check
which typing rules are present.
This also required some changes to tests:
- `ref_pat_eat_one_layer_2021.rs` had a test for Rule 3; I'll be
handling tests for earlier editions in a later commit, so as a stopgap
I've #[cfg]ed it out.
- One test case had to be moved from `well-typed-edition-2024.rs` to
`borrowck-errors.rs` in order to get borrowck to run on it and emit an
error.
These targets have always generated DWARF debuginfo and not CodeView/PDB debuginfo
like the MSVC Windows targets. Correct their target definitions to reflect this.
The newly added tests for the various combinations of `*-windows-gnu*` targets and
`-Csplit-debuginfo` show that this does not change any stable behavior.
Subtree sync for rustc_codegen_cranelift
Nothing too exciting this time, but this includes a fix for a linker hang on Windows: https://github.com/rust-lang/rustc_codegen_cranelift/pull/1554
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Partial progress on #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase
Part of #132735: Replace `extern "rust-intrinsic"` with `#[rustc_intrinsic]` macro
- Updated all instances of `extern "rust-intrinsic"` to use the `#[rustc_intrinsic]` macro.
- Skipped `.md` files and test files to avoid unnecessary changes.
Rollup of 5 pull requests
Successful merges:
- #135433 (Add Profile Override for Non-Git Sources)
- #135626 (doc: Point to methods on `Command` as alternatives to `set/remove_var`)
- #135658 (Do not include GCC source code in source tarballs)
- #135676 (rustc_resolve: use structured fields in traces)
- #135762 (Correct counting to four in cell module docs)
r? `@ghost`
`@rustbot` modify labels: rollup
When LLVM's location discriminator value limit is exceeded, emit locations with dummy spans instead of dropping them entirely
Dropping them fails `-Zverify-llvm-ir`.
Fixes#135332.
r? `@jieyouxu`
rustc_resolve: use structured fields in traces
I think this crate was written before `tracing` was adopted, and was manually writing fields into trace logs instead of using structured fields.
I kept function names in the trace messages even though I added `#[instrument]` invocations so that the events will be in named spans, wasn't sure if spans are always printed.
Rollup of 7 pull requests
Successful merges:
- #135542 (Add the concrete syntax for precise capturing to 1.82 release notes.)
- #135700 (Emit single privacy error for struct literal with multiple private fields and add test for `default_field_values` privacy)
- #135722 (make it possible to use ci-rustc on tarball sources)
- #135729 (Add debug assertions to compiler profile)
- #135736 (rustdoc: Fix flaky doctest test)
- #135738 (Replace usages of `map_or(bool, ...)` with `is_{some_and|none_or|ok_and}`)
- #135747 (Rename FileName::QuoteExpansion to CfgSpec)
r? `@ghost`
`@rustbot` modify labels: rollup
Always force non-trimming of path in `unreachable_patterns` lint
Creating a "trimmed DefID path" when no error is being emitted is an ICE (on purpose). If we create a trimmed path for a lint that is then silenced before being emitted causes a known ICE. This side-steps the issue by always using `with_no_trimmed_path!`.
This was verified to fix https://github.com/quinn-rs/quinn/, but couldn't write a repro case for the test suite.
Fix#135289.
Match Ergonomics 2024: document and reorganize the currently-implemented feature gates
The hope here is to make it easier to adjust, understand, and test the experimental pattern typing rules implemented in the compiler. This PR doesn't (or at isn't intended to) change any behavior or add any new tests; I'll be handling that later. I've also included some reasoning/commentary on the more involved changes in the commit messages.
Relevant tracking issue: #123076
r? `@Nadrieril`
fully de-stabilize all custom inner attributes
`#![test]` and `#![rustfmt::skip]` were accidentally accepted in more places than they should. These have been marked as soft-unstable since forever (https://github.com/rust-lang/rust/pull/82399) and shown in future-compat reports since Rust 1.77 (https://github.com/rust-lang/rust/pull/116274).
Cc `@rust-lang/lang` `@petrochenkov`
Rename FileName::QuoteExpansion to CfgSpec
I believe this variant name was used incorrectly. The timeline is roughly:
* `FileName::cfg_spec_source_code` was added in https://github.com/rust-lang/rust/pull/54517. However, it used `FileName::Quote` instead of `FileName::CfgSpec` which I believe was a mistake.
* Quote stuff was removed in https://github.com/rust-lang/rust/pull/51285, but did not remove `FileName::Quote`.
* `FileName::CfgSpec` was removed in https://github.com/rust-lang/rust/pull/116474 because it was unused.
This restores it so that the `--cfg` variant uses a name that makes more sense with how it is used, and restores what I think is the original intent.
Replace usages of `map_or(bool, ...)` with `is_{some_and|none_or|ok_and}`
Split out from #135732 according to https://github.com/rust-lang/rust/pull/135732?pullrequestreview-2561072330 ,
same thing but just for the compiler:
> The usage of `map_or(bool, ...)` is really hard to understand IMHO.
> This PR simply uses clippy (with `--fix`) to replace that with `is_{some_and|none_or|ok_and}`.
> (no manual modifications were made, just machine applicable clippy fixes and then fmt)
r? ``@compiler-errors``
Emit single privacy error for struct literal with multiple private fields and add test for `default_field_values` privacy
Add test ensuring that struct with default field values is not constructable if the fields are not accessible.
Collect all unreachable fields in a single struct literal struct and emit a single error, instead of one error per private field.
```
error[E0451]: fields `beta` and `gamma` of struct `Alpha` are private
--> $DIR/visibility.rs:18:13
|
LL | let _x = Alpha {
| ----- in this type
LL | beta: 0,
| ^^^^^^^ private field
LL | ..
| ^^ field `gamma` is private
```
This adds explanation of inherited references and how they relate to the default binding mode.
Co-authored-by: Nadrieril <Nadrieril@users.noreply.github.com>
I believe this variant name was used incorrectly. The timeline is roughly:
* `FileName::cfg_spec_source_code` was added in
https://github.com/rust-lang/rust/pull/54517. However, it used
`FileName::Quote` instead of `FileName::CfgSpec` which I believe was a
mistake.
* Quote stuff was removed in
https://github.com/rust-lang/rust/pull/51285, but did not remove
`FileName::Quote`.
* `FileName::CfgSpec` was removed in
https://github.com/rust-lang/rust/pull/116474 because it was unused.
This restores it so that the `--cfg` variant uses a name that makes more
sense with how it is used, and restores what I think is the original
intent.
Revert most of #133194 (except the test and the comment fixes). Then refix
not emitting locations at all when the correct location discriminator value
exceeds LLVM's capacity.
Don't skip argument parsing when running `rustc` with no arguments
Setting up the argument parser to parse no arguments is a tiny bit of wasted work, but avoids an otherwise-unnecessary special case, in a scenario (printing a help message and quitting) where perf at this scale really doesn't matter anyway.
In particular, this lets us avoid having to deal with multiple different APIs to determine whether the compiler is nightly or not.
---
This special-case handling for rustc with no arguments is very very old (long predating 1.0), and used to be much simpler, without any need to set up boolean values to handle various conditional cases. So I don't think it was ever explicitly decided that having this special case was worth the extra complexity; it just started out simple and accumulated complexity over time.
Setting up the argument parser to parse no arguments is a tiny bit of wasted
work, but avoids an otherwise-unnecessary special case.
In particular, this lets us avoid having to deal with multiple different APIs
to determine whether the compiler is nightly or not.
