The following is a weird pattern for a file within `rustc_middle`:
```
use rustc_middle::aaa;
use crate::bbb;
```
More sensible and standard would be this:
```
use crate::{aaa, bbb};
```
I.e. we generally prefer using `crate::` to using a crate's own name.
(Exceptions are things like in macros where `crate::` doesn't work
because the macro is used in multiple crates.)
This commit fixes a bunch of these weird qualifiers.
Show diff suggestion format on verbose replacement
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
before:
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL + let _ = 2.0f64;
| ~~~~
```
r? `@oli-obk`
compiler: gate `extern "{abi}"` in ast_lowering
I don't believe low-level crates like `rustc_abi` should have to know or care about higher-level concerns like whether the ABI string is stable for users. These implementation details can be made less open to public inspection. This way the code that governs stability is near the code that enforces stability, and compiled together.
It also abstracts away certain error messages instead of constantly repeating them.
A few error messages are simply deleted outright, instead of made uniform, because they are either too dated to be useful or redundant with other diagnostic improvements we could make. These can be pursued in followups: my first concern was making sure there wasn't unnecessary diagnostics-related code in `rustc_abi`, which is not well-positioned to understand what kind of errors are going to be generated based on how it is used.
r? ``@ghost``
Prevent generic pattern types from being used in libstd
Pattern types should follow the same rules that patterns follow. So a pattern type range must not wrap and not be empty. While we reject such invalid ranges at layout computation time, that only happens during monomorphization in the case of const generics. This is the exact same issue as other const generic math has, and since there's no solution there yet, I put these pattern types behind a separate incomplete feature.
These are not necessary for the pattern types MVP (replacing the layout range attributes in libcore and rustc).
cc #136574 (new tracking issue for the `generic_pattern_types` feature gate)
r? ``@lcnr``
cc ``@scottmcm`` ``@joshtriplett``
Delay bug when method confirmation cannot upcast object pick of self
Justification is on the test comment. Simply delays a bug that we were previously ICEing on.
cc ``@adetaylor`` since this is a `arbitrary_self_types` ICE.
Introduce CoercePointeeWellformed for coherence checks at typeck stage
Fix#135206
This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.
This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.
A following series of patch will arrive later to address the following concern.
1. #135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.
**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.
``@rustbot`` label F-derive_coerce_pointee
Pointers for variables all need to be in the same address space for
correct compilation. Therefore ensure that even if an `alloca` is
created in a different address space, it is casted to the default
address space before its value is used.
This is necessary for the amdgpu target and others where the default
address space for `alloca`s is not 0.
For example the following code compiles incorrectly when not casting the
address space to the default one:
```rust
fn f(p: *const i8 /* addrspace(0) */) -> *const i8 /* addrspace(0) */ {
let local = 0i8; /* addrspace(5) */
let res = if cond { p } else { &raw const local };
res
}
```
results in
```llvm
%local = alloca addrspace(5) i8
%res = alloca addrspace(5) ptr
if:
; Store 64-bit flat pointer
store ptr %p, ptr addrspace(5) %res
else:
; Store 32-bit scratch pointer
store ptr addrspace(5) %local, ptr addrspace(5) %res
ret:
; Load and return 64-bit flat pointer
%res.load = load ptr, ptr addrspace(5) %res
ret ptr %res.load
```
For amdgpu, `addrspace(0)` are 64-bit pointers, `addrspace(5)` are
32-bit pointers.
The above code may store a 32-bit pointer and read it back as a 64-bit
pointer, which is obviously wrong and cannot work. Instead, we need to
`addrspacecast %local to ptr addrspace(0)`, then we store and load the
correct type.
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
We cannot produce anything useful if asked to compile unknown targets.
We should handle the error immediately at the point of discovery instead
of propagating it upward, and preferably in the simplest way: Die.
This allows cleaning up our "error-handling" spread across 5 crates.
Disable DWARF in linker options for i686-unknown-uefi
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was added.
This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
```
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
```
This issue was originally raised here: https://github.com/rust-lang/rust/pull/119286#issuecomment-2612746162. See also https://github.com/rust-lang/rust/issues/136096. It was suggested to file an LLVM bug, but I don't think LLVM is actually doing anything wrong as such.
CC `@dvdhrm` `@jyn514` let me know if you have any feedback on this approach
rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync"
rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync"
We don't need to "short circuit trait resolution", because DynSend and DynSync are auto traits and thus coinductive
cc "Parallel Rustc Front-end" https://github.com/rust-lang/rust/issues/113349
r? SparrowLii
``@rustbot`` label: +WG-compiler-parallel
(rustbot sometimes ignores me and doesn't attach labels on my behalf. rustbot banned me?)
adding autodiff tests
I'd like to get started with upstreaming some tests, even though I'm still waiting for an answer on how to best integrate the enzyme pass. Can we therefore temporarily support the -Z llvm-plugins here without too much effort? And in that case, how would that work? I saw you can do remapping, e.g. `rust-src-base`, but I don't think that will give me the path to libEnzyme.so. Do you have another suggestion?
Other than that this test simply checks that the derivative of `x*x` is `2.0 * x`, which in this case is computed as
`%0 = fadd fast double %x.0.val, %x.0.val`
(I'll add a few more tests and move it to an autodiff folder if we can use the -Z flag)
r? ``@jieyouxu``
Locally at least `-Zllvm-plugins=${PWD}/build/x86_64-unknown-linux-gnu/enzyme/build/Enzyme/libEnzyme-19.so` seems to work if I copy the command I get from x.py test and run it manually. However, running x.py test itself fails.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Enzyme.20build.20changes
The wording unsafe pointer is less common and not mentioned in a lot of
places, instead this is usually called a "raw pointer". For the sake of
uniformity, we rename this method.
This came up during the review of
https://github.com/rust-lang/rust/pull/134424.
Removed dependency on the field-offset crate, alternate approach
This is an alternate approach to reach the same goals as #136003. As it touches the core of the query system, this too probably should be evaluated for performance.
r? ``@Mark-Simulacrum``
coverage: Defer part of counter-creation until codegen
Follow-up to #135481 and #135873.
One of the pleasant properties of the new counter-assignment algorithm is that we can stop partway through the process, store the intermediate state in MIR, and then resume the rest of the algorithm during codegen. This lets it take into account which parts of the control-flow graph were eliminated by MIR opts, resulting in fewer physical counters and simpler counter expressions.
Those improvements end up completely obsoleting much larger chunks of code that were previously responsible for cleaning up the coverage metadata after MIR opts, while also doing a more thorough cleanup job.
(That change also unlocks some further simplifications that I've kept out of this PR to limit its scope.)
It is speculated that these two can be conceptually merged, and it can
start by ripping out rustc's notion of the PtxKernel call convention.
Leave the ExternAbi for now, but the nvptx target now should see it as
just a different way to spell Conv::GpuKernel.
Add amdgpu target
Add amdgpu target to rustc and enable the LLVM target.
Fix compiling `core` with the amdgpu:
The amdgpu backend makes heavy use of different address spaces. This
leads to situations, where a pointer in one addrspace needs to be casted
to a pointer in a different addrspace. `bitcast` is invalid for this
case, `addrspacecast` needs to be used.
Fix compilation failures that created bitcasts for such cases by
creating pointer casts (which creates an `addrspacecast` under the hood)
instead.
MCP: https://github.com/rust-lang/compiler-team/issues/823
Tracking issue: #135024
Kinda related to the original amdgpu tracking issue #51575 (though that one has been closed for a while).
These are either residue of a long-term migration away from something,
or are simply trying too hard to be specifically useful:
nearest-match suggestions for ABI strings should handle this.
By moving this stability check into AST lowering, we effectively make
it impossible to accidentally miss, as it must happen to generate HIR.
Also, we put the ABI-stability code next to code that actually uses it!
This allows code that wants to reason about backend ABI implementations
to stop worrying about high-level concerns like syntax stability,
while still leaving it as the authority on what ABIs actually exist.
It also makes it easy to refactor things to have more consistent errors.
For now, we only apply this to generalize the existing messages a bit.
This fixes an lld warning:
> warning: linker stderr: rust-lld: section name .debug_frame is longer
> than 8 characters and will use a non-standard string table
See https://reviews.llvm.org/D69594 for details of where the warning was
added.
This warning only occurs with the i686 UEFI target, not x86_64 or
aarch64. The x86_64 target uses an LLVM target of
`x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but
i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in
`i686_unknown_uefi.rs` for details of why.
The `.debug_frame` section should not actually be needed; UEFI targets
provide a separate PDB file for debugging. Disable DWARF (and by
extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld.
Tested with:
export RUSTC_LOG=rustc_codegen_ssa:🔙:link=info
cargo +stage1 build --release --target i686-unknown-uefi
Visit all debug info in MIR Visitor
I've been experimenting with simplifying debug info in MIR inliner, and discovered that MIR Visitor doesn't reliably visit all spans. This PR adds the missing visitor calls.
DWARF 1 is very different than DWARF 2+ (see the commentary in
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf)
and LLVM does not really seem to support DWARF 1 as Clang does not offer
a `-gdwarf-1` flag and `llc` will just generate DWARF 2 with the version
set to 1: https://godbolt.org/z/s85d87n3a.
Since this isn't actually supported (and it's not clear it would be
useful anyway), report that DWARF 1 is not supported if it is requested.
Also add a help message to the error saying which versions are supported.
Update bootstrap compiler and rustfmt
The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same
time.
Rollup of 5 pull requests
Successful merges:
- #134679 (Windows: remove readonly files)
- #136213 (Allow Rust to use a number of libc filesystem calls)
- #136530 (Implement `x perf` directly in bootstrap)
- #136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull)
- #136659 (Pick the max DWARF version when LTO'ing modules with different versions )
r? `@ghost`
`@rustbot` modify labels: rollup
Small resolve refactor
I was looking into how resolve works in order to find a good way for clippy to shorten paths in messages and suggestions, and found a needless `.collect()` and a recursive function that could be written as a loop, also removed a panicky code path.
transmutability: fix ICE when passing wrong ADT to ASSUME
- Remove an incorrect assert that the `ASSUME` parameter has the type `Assume` and delay a bug instead.
- Since we checked the type of `ASSUME` is `Assume` (an ADT), its valtree must be a branch, so we can just unwrap it.
r? ```@jswrenn```
compiler: mostly-finish `rustc_abi` updates
This almost-finishes all the updates in the compiler to use `rustc_abi` and removes some of the reexports of `rustc_abi` items in `rustc_target` that were previously available.
r? ```@compiler-errors```
Pick the max DWARF version when LTO'ing modules with different versions
Currently, when rustc compiles code with `-Clto` enabled that was built
with different choices for `-Zdwarf-version`, a warning will be
reported. It's very easy to observe this by compiling most anything (eg,
"hello world") and specifying `-Clto -Zdwarf-version=5` since the
standard library is distributed with `-Zdwarf-version=4`.
This behavior isn't actually useful for a few reasons:
- From observation, LLVM chooses to pick the highest DWARF version
anyway after issuing the warning.
- Clang specifies that in this case, the max version should be picked
without a warning and as a general principle, we want to support
x-lang LTO with Clang which implies using the same module flag merge
behaviors.
- Debuggers need to be able to handle a variety of versions within the
same debugging session as you can easily have some parts of a binary
(or some dynamic libraries within an application) all compiled with
different DWARF versions.
This commit changes the module flag merge behavior to match Clang and
use the highest version of DWARF. It also adds a test to ensure this
behavior is respected in the case of two crates being LTO'd together and
adds a test to ensure no warning is printed.
Fixes#130041 which fails due to these warnings being printed
cc #103057
Make empty-line-after an early clippy lint
r? ```@y21```
95% a refiling of https://github.com/rust-lang/rust-clippy/pull/13658 but for correctness it needed 2 extra methods in `rust_lint` which made it much easier to apply on `rust-lang/rust` than `rust-lang/rust-clippy`.
Commits have been thoroughly reviewed on `rust-lang/clippy already`. The last two review comments there (about using `Option` and popping for assoc items have been applied here.
Generate correct terminate block under Wasm EH
This fixes failing LLVM assertions during insnsel.
Improves #135665.
r? bjorn3
^ you reviewed the PR bringing Wasm EH in, I assume this is within your area of expertise?
Subtree sync for rustc_codegen_cranelift
The main highlights this time are a Cranelift update and a fix for a warning that the x87 feature is not enabled.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler<!-- homu-ignore:start -->
Currently, when rustc compiles code with `-Clto` enabled that was built
with different choices for `-Zdwarf-version`, a warning will be
reported. It's very easy to observe this by compiling most anything (eg,
"hello world") and specifying `-Clto -Zdwarf-version=5` since the
standard library is distributed with `-Zdwarf-version=4`.
This behavior isn't actually useful for a few reasons:
- from observation, LLVM chooses to pick the highest DWARF version
anyway after issuing the warning
- Clang specifies that in this case, the max version should be picked
without a warning and as a general principle, we want to support
x-lang LTO with Clang which implies using the same module flag merge
behaviors
- Debuggers need to be able to handle a variety of versions withing the
same debugging session as you can easily have some parts of a binary
(or some dynamic libraries within an application) all compiled with
different DWARF versions
This commit changes the module flag merge behavior to match Clang and
use the highest version of DWARF. It also adds a test to ensure this
behavior is respected in the case of two crates being LTO'd together and
updates the test added in the previous commit to ensure no warning is
printed.
Rollup of 6 pull requests
Successful merges:
- #136640 (Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit)
- #136648 (Add a missing `//@ needs-symlink` to `tests/run-make/libs-through-symlinks`)
- #136651 (Label mismatched parameters at the def site for foreign functions)
- #136691 (Remove Linkage::Private and Linkage::Appending)
- #136692 (add module level doc for bootstrap:utils:exec)
- #136700 (i686-unknown-hurd-gnu: bump baseline CPU to Pentium 4)
r? `@ghost`
`@rustbot` modify labels: rollup
Label mismatched parameters at the def site for foreign functions
Nice and simple. Adds parameter marking for the only missing definition type.
r? ``@compiler-errors``
Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit
In #116096, function ZSTs were made to have debuginfo that gives them an alignment of “1”. But because alignment in LLVM debuginfo is denoted in *bits*, not bytes, this resulted in an alignment specification of 1 bit instead of 1 byte.
I don't know whether this has any practical consequences, but I noticed that a test started failing when I accidentally fixed the mistake while working on #136632, so I extracted the fix (and the test adjustment) to this PR.
Rollup of 7 pull requests
Successful merges:
- #135179 (Make sure to use `Receiver` trait when extracting object method candidate)
- #136554 (Add `opt_alias_variances` and use it in outlives code)
- #136556 ([AIX] Update tests/ui/wait-forked-but-failed-child.rs to accomodate exiting and idle processes.)
- #136589 (Enable "jump to def" feature on rustc docs)
- #136615 (sys: net: Add UEFI stubs)
- #136635 (Remove outdated `base_port` calculation in std net test)
- #136682 (Move two windows process tests to tests/ui)
r? `@ghost`
`@rustbot` modify labels: rollup
Enable "jump to def" feature on rustc docs
This PR enables the rustdoc "jump to def" feature which is visible on the source code pages.
r? ``@oli-obk``
Add `opt_alias_variances` and use it in outlives code
...so to fix some subtle outlives bugs with precise capturing in traits, and eventually make it easier to compute variances for "forced unconstrained" trait lifetimes.
r? lcnr
Make sure to use `Receiver` trait when extracting object method candidate
In method confirmation, the `extract_existential_trait_ref` function re-extracts the object type by derefing until it reaches an object. If we're assembling methods via the `Receiver` trait, make sure we re-do our work also using the receiver trait.
Fixes#135155
cc ``@adetaylor``
Remove dead code from rustc_codegen_llvm and the LLVM wrapper
First step to clean up the LLVM wrapper: remove existing dead code.
Split out of #135502
r? ``@Zalathar``
Pattern Migration 2024: try to suggest eliding redundant binding modifiers
This is based on #136475. Only the last commit is new.
This is a simpler, more restrictive alternative to #136496, meant to partially address #136047. If a pattern can be migrated to Rust 2024 solely by removing redundant binding modifiers, this will make that suggestion; otherwise, it uses the old suggestion of making the pattern fully explicit.
Relevant tracking issue: #131414
``@rustbot`` label A-diagnostics A-patterns A-edition-2024
r? ``@Nadrieril``
MIR validation: add comment explaining the limitations of CfgChecker
I hope this right but I am not sure.^^
Cc `@compiler-errors` `@lcnr` `@cjgillot` `@oli-obk`
compiler: Clean up weird `rustc_abi` reexports
Just general cleanup in `rustc_target` and `rustc_abi`. I was originally going to make a PR with a larger change that also fixed the last few crates and in doing so removed some clutter from `rustc_abi`, but wound up slightly stuck on it, then figured out how to fix it, and then got distracted by other things... so now I'm trying to figure out what I had figured out earlier.
fix tail call checks wrt `#[track_caller]`
Only check the caller + disallow caller having the attribute.
fixes#134336
r? `@compiler-errors`
<sub>apparently there were no tests for `#[track_caller]` before... ooops</sub>
Don't reset cast kind without also updating the operand in `simplify_cast` in GVN
Consider this heavily elided segment of the pre-GVN example code that was committed as a test:
```rust
let _4: *const ();
let _5: *const [()];
let mut _6: *const ();
let _7: *mut ();
let mut _8: *const [()];
let mut _9: std::boxed::Box<()>;
let mut _10: *const ();
/* ... */
// Deref a box
_10 = copy ((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>) as *const () (Transmute);
_4 = copy _10;
_6 = copy _4;
// Inlined body of `slice::from_raw_parts`, to turn a unit pointer into a slice-of-unit pointer
_5 = *const [()] from (copy _6, copy _11);
_8 = copy _5;
// Cast the raw slice-of-unit pointer back to a unit pointer
_7 = copy _8 as *mut () (PtrToPtr);
```
A malformed optimization was changing `_7` (which casted the slice-of-unit ptr to a unit ptr) to:
```
_7 = copy _5 as *mut () (Transmute);
```
...where `_8` was just replaced with `_5` bc of simple copy propagation, that part is not important... the CastKind changing to Transmute is the important part here.
In #133324, two new functionalities were implemented:
* Peeking through unsized -> sized PtrToPtr casts whose operand is `AggregateKind::RawPtr`, to turn it into PtrToPtr casts of the base of the aggregate. In this case, this allows us to see that the value of `_7` is just a ptr-to-ptr cast of `_6`.
* Folding a PtrToPtr cast of an operand which is a Transmute cast into just a single Transmute, which (theoretically) allows us to treat `_7` as a transmute into `*mut ()` of the base of the cast of `_10`, which is the place projection of `((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>)`.
However, when applying those two subsequent optimizations, we must *not* update the CastKind of the final cast *unless* we also update the operand of the cast, since the operand may no longer make sense with the updated CastKind.
In this case, this is problematic because the type of `_8` is `*const [()]`, but that operand in assignment statement of `_7` does *not* get turned into something like `((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>)` -- **in other words, `try_to_operand` fails** -- because GVN only turns value nodes into locals or consts, not projections of locals. So we fail to update the operand, but we still update the CastKind to Transmute, which means we now are transmuting types of different sizes (a wide pointer and a thin pointer).
r? `@scottmcm` or `@cjgillot`
Fixes#136361Fixes#135997
this commit makes `deref_into_dyn_supertrait` lint allow-by-default,
removes future incompatibility (we finally live in a broken world), and
changes the wording in the documentation.
previously documentation erroneously said that it lints against *usage*
of the deref impl, while it actually (since 104742) lints on the impl
itself (oooops, my oversight, should have updated it 2+ years ago...)
Simplify slice indexing in next trait solver
Unless I'm missing something:
- no need to explicitly specify the end of the slice as the end of the index range
- the `assert` is redundant since the indexing will panic for the same condition
I think this change simplifies it a bit. Also replaced the `for` loop of `push`es with a call to `extend` with an iterator. Might improve performance since it knows how many elements will be added beforehand and can pre-reserve room?
r? `@compiler-errors` , I think
Rollup of 7 pull requests
Successful merges:
- #136073 (Always compute coroutine layout for eagerly emitting recursive layout errors)
- #136235 (Pretty print pattern type values with transmute if they don't satisfy their pattern)
- #136311 (Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types)
- #136315 (Use short ty string for binop and unop errors)
- #136393 (Fix accidentally not emitting overflowing literals lints anymore in patterns)
- #136435 (Simplify some code for lowering THIR patterns)
- #136630 (Change two std process tests to not output to std{out,err}, and fix test suite stat reset in bootstrap CI test rendering)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-gnu-debug
Simplify some code for lowering THIR patterns
I've been playing around with some radically different ways of storing THIR patterns, and while those experiments haven't yet produced a clear win, I have noticed various smaller things in the existing code that can be made a bit nicer.
Some of the more significant changes:
- With a little bit of extra effort (and thoughtful use of Arc), we can completely remove an entire layer of `'pat` lifetimes from the intermediate data structures used for match lowering.
- In several places, lists of THIR patterns were being double-boxed for no apparent reason.
Fix accidentally not emitting overflowing literals lints anymore in patterns
This was regressed in https://github.com/rust-lang/rust/pull/134228 (not in beta yet).
The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code.
So now I've set it up for visitors to be able to directly visit literals and get all literals
Use short ty string for binop and unop errors
```
error[E0369]: cannot add `(..., ..., ..., ...)` to `(..., ..., ..., ...)`
--> $DIR/binop.rs:10:7
|
LL | x + x;
| - ^ - (..., ..., ..., ...)
| |
| (..., ..., ..., ...)
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
```
error[E0600]: cannot apply unary operator `!` to type `(..., ..., ..., ...)`
--> $DIR/binop.rs:14:5
|
LL | !x;
| ^^ cannot apply unary operator `!`
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
CC #135919.
Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types
Check for impossible obligations in the `dyn Trait` type we're trying to compute its the vtable upcasting and method call slots.
r? lcnr
Pretty print pattern type values with transmute if they don't satisfy their pattern
Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`.
These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code.
follow-up to https://github.com/rust-lang/rust/pull/136176
cc ``@compiler-errors`` ``@scottmcm``
r? ``@RalfJung`` because of the interpreter changes
Always compute coroutine layout for eagerly emitting recursive layout errors
Detect recursive coroutine layouts even if we don't detect opaque type recursion in the new solver. This is for two reasons:
1. It helps us detect (bad) recursive async function calls in the new solver, which due to its approach to normalization causes us to not detect this via a recursive RPIT (since the opaques are more eagerly revealed in the opaque body).
* Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/137.
2. It helps us detect (bad) recursive async functions behind AFITs. See the AFIT test that changed for the old solver too.
3. It also greatly simplifies the recursive impl trait check, since I can remove some jankness around how it handles coroutines.
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`
This is continuation of https://github.com/rust-lang/rust/pull/132282 .
I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement.
There are other possibilities, through.
We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase.
So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge.
cc "Parallel Rustc Front-end" ( https://github.com/rust-lang/rust/issues/113349 )
r? SparrowLii
`@rustbot` label WG-compiler-parallel
General housekeeping:
- Use less reexports from its rustc_target era
- Unify some imports as a result
- Split the Reg(ister) types into their own files
Generally moving stuff around because it makes the crate more consistent.
rustc_target has had a lot of weird reexports for various reasons, but
now we're at a point where we can actually start reducing their number.
We remove weird shadowing-dependent behavior and import directly from
rustc_abi instead of doing weird renaming imports.
This is only incremental progress and does not entirely fix the crate.
cg_llvm: Remove the `mod llvm_` hack, which should no longer be necessary
This re-export was introduced in c76fc3d804, as a workaround for #53912.
In short, there was/is an assumption in some LLVM LTO code that symbol names would not contain `.llvm.`, but legacy symbol mangling would naturally produce that sequence for symbols in a module named `llvm`.
This was later “fixed” by adding a special case to the legacy symbol mangler in #61195, which detects the sequence `llvm` and emits the `m` in an escaped form. As a result, there should no longer be any need to avoid the module name `llvm` in the compiler itself.
(Symbol mangling v0 avoids this problem by not using `.` in the first place, outside of the “vendor-specific suffix”.)
Only highlight unmatchable parameters at the definition site
Followup to #136497
This generally results more focused messages in the same vein as #99635 (see `test/ui/argument-suggestions/complex.rs`). There are still some cases (e.g. `test/ui/argument-suggestions/permuted_arguments.rs`) where it might be worth highlighting the arguments. This is mitigated by the fact that a suggestion with a suggested rearrangement is given.
r? `@compiler-errors`
Document why some "type mismatches" exist
Just something I stumbled over and thought to save myself (and maybe others) the research time when encountering it again.
Pass spans around new solver
...so that when we instantiate canonical responses, we can actually have region obligations with the right span.
Within the solver itself, we still use dummy spans everywhere.
Avoid using make_direct_deprecated() in extern "ptx-kernel"
This method will be removed in the future as it produces a broken ABI that depends on cg_llvm implementation details. After this PR wasm32-unknown-unknown is the only remaining user of make_direct_deprecated().
Fixes https://github.com/rust-lang/rust/issues/117271
Blocks https://github.com/rust-lang/rust/issues/38788
We have four macros for generating trivial traversal (fold/visit) and
lift impls.
- `rustc_ir::TrivialTypeTraversalImpls`
- `rustc_middle::TrivialTypeTraversalImpls`
- `rustc_middle::TrivialLiftImpls`
- `rustc_middle::TrivialTypeTraversalAndLiftImpls`
The first two are very similar. The last one just combines the second
and third one.
The macros themselves are ok, but their use is a mess. This commit does
the following.
- Removes types that no longer need a lift and/or traversal impl from
the macro calls.
- Consolidates the macro calls into the smallest number of calls
possible, with each one mentioning as many types as possible.
- Orders the types within those macro calls alphabetically, and makes
the module qualification more consistent.
- Eliminates `rustc_middle::mir::type_foldable`, because the macro calls
were merged and the manual `TypeFoldable` impls are better placed in
`structural_impls.rs`, alongside all the other ones.
This makes the code more concise. Moving forward, it also makes it more
obvious where new types should be added.
Reject negative literals for unsigned or char types in pattern ranges and literals
It sucks a bit that we have to duplicate the work here (normal expressions just get this for free from the `ExprKind::UnOp(UnOp::Neg, ...)` typeck logic.
In https://github.com/rust-lang/rust/pull/134228 I caused
```rust
fn main() {
match 42_u8 {
-10..255 => {},
_ => {}
}
}
```
to just compile without even a lint.
I can't believe we didn't have tests for this
Amusingly https://github.com/rust-lang/rust/pull/136302 will also register a delayed bug in `lit_to_const` for this, so we'll have a redundancy if something like this fails again.
Upgrade elsa to the newest version.
This was locked to 1.7.1 because of an error in the elsa release process that has since been fixed. Upgrading has the advantage that the elsa code runs properly in miri, at least with tree borrows.
This was spawned from https://github.com/rust-lang/rust/issues/135870#issuecomment-2612470540
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 1)
Part of #134001, follow-up to #136326, extracted from #134009.
This PR performs an arbitrary subset of the LLVM-C binding migrations from #134009, which should make it less tedious to review. The remaining migrations can occur in one or more subsequent PRs.
#[contracts::requires(...)] + #[contracts::ensures(...)]
cc https://github.com/rust-lang/rust/issues/128044
Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition, building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).
Known issues:
* My original intent, as described in the MCP (https://github.com/rust-lang/compiler-team/issues/759) was to have a rustc-prefixed attribute namespace (like rustc_contracts::requires). But I could not get things working when I tried to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it is called `contracts::requires`.
* Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
* (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)
* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
Shard AllocMap Lock
This improves performance on many-seed parallel (-Zthreads=32) miri executions from managing to use ~8 cores to using 27-28 cores, which is about the same as what I see with the data structure proposed in https://github.com/rust-lang/rust/pull/136105 - I haven't analyzed but I suspect the sharding might actually work out better if we commonly insert "densely" since sharding would split the cache lines and the OnceVec packs locks close together. Of course, we could do something similar with the bitset lock too.
Either way, this seems like a very reasonable starting point that solves the problem ~equally well on what I can test locally.
r? `@RalfJung`
mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers`
A combination of two loosely-related tweaks that would otherwise conflict with each other:
- `Cx` is a pretty unhelpful type name, especially when jumping between THIR-building and MIR-building while trying to make changes to THIR data structures.
- The `UserAnnotatedTyHelpers` trait doesn't appear to provide any benefit over a simple helper function, and its `tcx()` method is currently completely unnecessary.
No functional change.
Remove unnecessary layout assertions for object-safe receivers
The soundness of `DispatchFromDyn` relies on the fact that, like all other built-in marker-like layout traits (e.g. `Sized`, `CoerceUnsized`), the guarantees that they enforce in *generic* code via traits will result in assumptions that we can rely on in codegen.
Specifically, `DispatchFromDyn` ensures that we end up with a receiver that is a valid pointer type, and its implementation validity recursively ensures that the ABI of that pointer type upholds the `Scalar` or `ScalarPair` representation for sized and unsized pointees, respectively.
The check that this layout guarantee holds for arbitrary, possibly generic receiver types that also may exist in possibly impossible-to-instantiate where clauses is overkill IMO, and leads to several ICEs due to the fact that computing layouts before monomorphization is going to be fallible at best.
This PR removes the check altogether, since it just exists as a sanity check from very long ago, 6f2a161b1b.
Fixes#125810Fixes#90110
This PR is an alternative to #136195. cc `@adetaylor.` I didn't realize in that PR that the layout checks that were being modified were simply *sanity checks*, rather than being actually necessary for soundness.
Report generic mismatches when calling bodyless trait functions
Don't know if there's an open issue for this. Just happened to notice this when working in that area.
The awkward extra spans added to the diagnostics of some tests (e.g. `trait-with-missing-associated-type-restriction`) is consistent with what happens for normal functions. Should probably be removed since that span doesn't seem to note anything useful.
First and third commit are both cleanups removing some unnecessary work. Second commit has the actual fix.
fixes#135124
Fix a couple NLL TLS spans
Some NLL TLS tests show incorrect spans for the end of function. It seems that the `TerminatorKind::Return` source info span can sometimes point at the single character after the end of the function.
Completely changing the span where the terminator is built also changes a bunch of diagnostics: small functions have more code shown unrelated to the errors at hand, wrapping symbols appear and weird-looking arrows point to the end of function, etc. So it seems this is somehow unexpectedly relied upon in making diagnostics look better and their heuristics.
So I just changed it where it matters for these few tests: the diagnostics specialized to conflict errors with thread locals.
r? `@matthewjasper`
Allow using named consts in pattern types
This required a refactoring first: I had to stop using `hir::Pat`in `hir::TyKind::Pat` and instead create a separate `TyPat` that has `ConstArg` for range ends instead of `PatExpr`. Within the type system we should be using `ConstArg` for all constants, as otherwise we'd be maintaining two separate const systems that could diverge. The big advantage of this PR is that we now inherit all the rules from const generics and don't have a separate system. While this makes things harder for users (const generic rules wrt what is allowed in those consts), it also means we don't accidentally allow some things like referring to assoc consts or doing math on generic consts.
This changed in llvm/llvm-project@91cb8f5d32.
The commit itself is mostly about some intrinsic instructions, but as an
aside it also mentions something about addrspace for tensor memory,
which I believe is what this string is telling us.
@rustbot label: +llvm-main
Implement unstable `new_range` feature
Switches `a..b`, `a..`, and `a..=b` to resolve to the new range types.
For rust-lang/rfcs#3550
Tracking issue #123741
also adds the re-export that was missed in the original implementation of `new_range_api`
Rollup of 6 pull requests
Successful merges:
- #134807 (fix(rustdoc): always use a channel when linking to doc.rust-lang.org)
- #134814 (Add `kl` and `widekl` target features, and the feature gate)
- #135836 (bootstrap: only build `crt{begin,end}.o` when compiling to MUSL)
- #136022 (Port ui/simd tests to use the intrinsic macro)
- #136309 (set rustc dylib on manually constructed rustc command)
- #136462 (mir_build: Simplify `lower_pattern_range_endpoint`)
r? `@ghost`
`@rustbot` modify labels: rollup
mir_build: Simplify `lower_pattern_range_endpoint`
By accumulating ascriptions and inline-consts in separate vectors, we can streamline some previously-tricky code for dealing with range patterns.
Add `kl` and `widekl` target features, and the feature gate
This is an effort towards #134813. This PR adds the target-features and the feature gate to `rustc`
<!--
```@rustbot``` label O-x86_64 O-x86_32 A-target-feature
r? compiler
-->
Rollup of 8 pull requests
Successful merges:
- #136289 (OnceCell & OnceLock docs: Using (un)initialized consistently)
- #136299 (Ignore NLL boring locals in polonius diagnostics)
- #136411 (Omit argument names from function pointers that do not have argument names)
- #136430 (Use the type-level constant value `ty::Value` where needed)
- #136476 (Remove generic `//@ ignore-{wasm,wasm32,emscripten}` in tests)
- #136484 (Notes on types/traits used for in-memory query caching)
- #136493 (platform-support: document CPU baseline for x86-32 targets)
- #136498 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
This has now been approved as a language feature and no longer needs
a `rustc_` prefix.
Also change the `contracts` feature to be marked as incomplete and
`contracts_internals` as internal.
1. Document the new intrinsics.
2. Make the intrinsics actually check the contract if enabled, and
remove `contract::check_requires` function.
3. Use panic with no unwind in case contract is using to check for
safety, we probably don't want to unwind. Following the same
reasoning as UB checks.
Instead of parsing the different components of a function signature,
eagerly look for either the `where` keyword or the function body.
- Also address feedback to use `From` instead of `TryFrom` in cranelift
contract and ubcheck codegen.
The extended syntax for function signature that includes contract clauses
should never be user exposed versus the interface we want to ship
externally eventually.
`rustc_middle` and `rustc_query_system` both have a file called
`dep_node.rs` with a big comment at the top, and the comments are very
similar. The one in `rustc_query_system` looks like the original, and
the one in `rustc_middle` is a copy with some improvements.
This commit removes the comment from `rustc_middle` and updates the one
in `rustc_query_system` to include the improvements. I did it this way
because `rustc_query_system` is the crate that defines `DepNode`, and so
seems like the right place for the comment.
includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures.
includes post-developed commit: removed tabs that creeped in into rustfmt tool source code.
includes post-developed commit, placating rustfmt self dogfooding.
includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/
includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures).
Rebase Conflicts:
- compiler/rustc_parse/src/parser/diagnostics.rs
- compiler/rustc_parse/src/parser/item.rs
- compiler/rustc_span/src/hygiene.rs
Remove contracts keywords from diagnostic messages
Notes on types/traits used for in-memory query caching
When the word "cache" appears in the context of the query system, it often isn't obvious whether that is referring to the in-memory query cache or the on-disk incremental cache.
For these types, we can assure the reader that they are for in-memory caching.
Use the type-level constant value `ty::Value` where needed
**Follow-up to #136180**
### Summary
This PR refactors functions to accept a single type-level constant value `ty::Value` instead of separate `ty::ValTree` and `ty::Ty` parameters:
- `valtree_to_const_value`: now takes `ty::Value`
- `pretty_print_const_valtree`: now takes `ty::Value`
- Uses `pretty_print_const_valtree` for formatting valtrees when `visit_const_operand`
- Moves `try_to_raw_bytes` from `ty::Valtree` to `ty::Value`
---
r? ``@lukas-code`` ``@oli-obk``
Ignore NLL boring locals in polonius diagnostics
Another easy one ``@jackh726`` (the diff is inflated by blessed test expectations don't worry :)
NLLs don't compute liveness for boring locals, and therefore cannot find them in causes explaining borrows. In polonius, we don't have this liveness optimization (we may be able to do something partially similar in the future, e.g. for function parameters and the like), so we do encounter these in diagnostics even though we don't want to. This PR:
- restructures the polonius context into per-phase data, in spirit as you requested in an earlier review
- stores the locals NLLs would consider boring into the errors/diagnostics data
- ignores these if a boring local is found when trying to explain borrows
This PR fixes around 80 cases of diagnostics differences between `-Zpolonius=next` and NLLs. I've also added explicit revisions to a few polonius tests (both for the in-tree implementation as well as the datalog implementation -- even if we'll eventually remove them). I didn't do this for all the "dead" expectations that were removed from #136112 for that same reason, it's fine. I'll soon/eventually add explicit revisions where they're needed: there's only a handful of tests left to fix.
r? ``@jackh726``
Explicitly choose x86 softfloat/hardfloat ABI
Part of https://github.com/rust-lang/rust/pull/135408:
Instead of choosing this based on the target features listed in the target spec, make that choice explicit.
All built-in targets are being updated here; custom (JSON-defined) x86 (32bit and 64bit) softfloat targets need to explicitly set `rustc-abi` to `x86-softfloat`.
When we suggest specifying a type for an expression or pattern, like in a `let` binding, we previously would print the entire type as the type system knew it. We now look at the params that have *no* inference variables, so they are fully known to the type system which means that they don't need to be specified.
This helps in suggestions for types that are really long, because we can usually skip most of the type params and make the annotation as short as possible:
```
error[E0282]: type annotations needed for `Result<_, ((..., ..., ..., ...), ..., ..., ...)>`
--> $DIR/really-long-type-in-let-binding-without-sufficient-type-info.rs:7:9
|
LL | let y = Err(x);
| ^ ------ type must be known at this point
|
help: consider giving `y` an explicit type, where the type for type parameter `T` is specified
|
LL | let y: Result<T, _> = Err(x);
| ++++++++++++++
```
Rollup of 8 pull requests
Successful merges:
- #136356 (Docs for f16 and f128: correct a typo and add details)
- #136404 (Remove a footgun-y feature / relic of the past from the compiletest DSL)
- #136432 (LTA: Actually check where-clauses for well-formedness at the def site)
- #136438 (miri: improve error when offset_from preconditions are violated)
- #136441 ([`compiletest`-related cleanups 1/7] Cleanup `is_rustdoc` logic and remove a useless path join in rustdoc-json runtest logic)
- #136455 (Remove some `Clone` bounds and derives.)
- #136464 (Remove hook calling via `TyCtxtAt`.)
- #136467 (override default config profile on tarballs)
r? `@ghost`
`@rustbot` modify labels: rollup
This removes support for attributes on struct field rest patterns (the `..`) from the parser.
Previously they were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
Add a couple of missing `ensure_sufficient_stacks`
r? `@saethlin` I hope you didn't spend time on this already.
(I couldn't sleep, opened `check_tail_calls`, there was a single call where it could happen, might as well fix it)
This PR adds a couple of missing `ensure_sufficient_stack`s:
- one in `check_tail_calls` that prevented the #135709 backport on some targets.
- after that was fixed, the test still didn't pass starting at 4MB, so I also added one in `check_unsafety` and that made it pass.
I didn't add an `rmake` test purposefully limiting the min stack size on `issue-74564-if-expr-stack-overflow.rs`, but we could if we wanted to.
On `apple-aarch64-darwin`, this is enough to make `RUST_MIN_STACK=$((1024*1024*3)) ./x test tests/ui --test-args tests/ui/issues/issue-74564-if-expr-stack-overflow.rs` pass for me locally, and it does stack overflow otherwise.
When the word "cache" appears in the context of the query system, it often
isn't obvious whether that is referring to the in-memory query cache or the
on-disk incremental cache.
For these types, we can assure the reader that they are for in-memory caching.
Remove hook calling via `TyCtxtAt`.
All hooks receive a `TyCtxtAt` argument.
Currently hooks can be called through `TyCtxtAt` or `TyCtxt`. In the latter case, a `TyCtxtAt` is constructed with a dummy span and passed to the hook.
However, in practice hooks are never called through `TyCtxtAt`, and always receive a dummy span. (I confirmed this via code inspection, and double-checked it by temporarily making the `TyCtxtAt` code path panic and running all the tests.)
This commit removes all the `TyCtxtAt` machinery for hooks. All hooks now receive `TyCtxt` instead of `TyCtxtAt`. There are two existing hooks that use `TyCtxtAt::span`: `const_caller_location_provider` and `try_destructure_mir_constant_for_user_output`. For both hooks the span is always a dummy span, probably unintentionally. This dummy span use is now explicit. If a non-dummy span is needed for these two hooks it would be easy to add it as an extra argument because hooks are less constrained than queries.
r? `@oli-obk`
LTA: Actually check where-clauses for well-formedness at the def site
All of the added tests used to wrongfully pass.
r? oli-obk or types/compiler or reassign
This aligns the main error message a bit more with the phrasing in the
Edition Guide and provides a bit more information on the labels to
(hopefully!) aid in understanding.
Target modifiers (special marked options) are recorded in metainfo
Target modifiers (special marked options) are recorded in metainfo and compared to be equal in different linked crates.
PR for this RFC: https://github.com/rust-lang/rfcs/pull/3716
Option may be marked as `TARGET_MODIFIER`, example: `regparm: Option<u32> = (None, parse_opt_number, [TRACKED TARGET_MODIFIER]`.
If an TARGET_MODIFIER-marked option has non-default value, it will be recorded in crate metainfo as a `Vec<TargetModifier>`:
```
pub struct TargetModifier {
pub opt: OptionsTargetModifiers,
pub value_name: String,
}
```
OptionsTargetModifiers is a macro-generated enum.
Option value code (for comparison) is generated using `Debug` trait.
Error example:
```
error: mixing `-Zregparm` will cause an ABI mismatch in crate `incompatible_regparm`
--> $DIR/incompatible_regparm.rs:10:1
|
LL | #![crate_type = "lib"]
| ^
|
= help: the `-Zregparm` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
= note: `-Zregparm=1` in this crate is incompatible with `-Zregparm=2` in dependency `wrong_regparm`
= help: set `-Zregparm=2` in this crate or `-Zregparm=1` in `wrong_regparm`
= help: if you are sure this will not cause problems, use `-Cunsafe-allow-abi-mismatch=regparm` to silence this error
error: aborting due to 1 previous error
```
`-Cunsafe-allow-abi-mismatch=regparm,reg-struct-return` to disable list of flags.
All hooks receive a `TyCtxtAt` argument.
Currently hooks can be called through `TyCtxtAt` or `TyCtxt`. In the
latter case, a `TyCtxtAt` is constructed with a dummy span and passed to
the hook.
However, in practice hooks are never called through `TyCtxtAt`, and
always receive a dummy span. (I confirmed this via code inspection, and
double-checked it by temporarily making the `TyCtxtAt` code path panic
and running all the tests.)
This commit removes all the `TyCtxtAt` machinery for hooks. All hooks
now receive `TyCtxt` instead of `TyCtxtAt`. There are two existing hooks
that use `TyCtxtAt::span`: `const_caller_location_provider` and
`try_destructure_mir_constant_for_user_output`. For both hooks the span
is always a dummy span, probably unintentionally. This dummy span use is
now explicit. If a non-dummy span is needed for these two hooks it would
be easy to add it as an extra argument because hooks are less
constrained than queries.
This does mean that we have to resolve the list of arm IDs twice, but it's
unclear whether that even matters, whereas the cleaner signature is a nice
improvement.
Explain why we retroactively change a static initializer to have a different type
I keep getting confused about it and in turn confused `@GuillaumeGomez` while trying to explain it badly
Shorten error message for callable with wrong return type
```
error: expected `{closure@...}` to return `Ret`, but it returns `Other`
```
instead of
```
error: expected `{closure@...}` to be a closure that returns `Ret`, but it returns `Other`
```
Test validity of pattern types
r? `@RalfJung`
pulled out of #136006 so we don't have to rely on libcore types excercising this code path
There's nothing to fix. `rustc_layout_scalar_valid_range_start` structs just failed their validation on their value instead of their fields' value, causing a diff where moving to pattern types adds an additional `.0` field access to the validation error
```
error[E0369]: cannot add `((..., ..., ..., ...), ..., ..., ...)` to `((..., ..., ..., ...), ..., ..., ...)`
--> $DIR/binop.rs:9:7
|
LL | x + x;
| - ^ - ((..., ..., ..., ...), ..., ..., ...)
| |
| ((..., ..., ..., ...), ..., ..., ...)
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
```
error[E0600]: cannot apply unary operator `!` to type `(..., ..., ..., ...)`
--> $DIR/binop.rs:14:5
|
LL | !x;
| ^^ cannot apply unary operator `!`
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
CC #135919.
rustc_allowed_through_unstable_modules: require deprecation message
This changes the `#[rustc_allowed_through_unstable_modules]` attribute so that a deprecation message (ideally directing people towards the stable path) is required.
Convert two `rustc_middle::lint` functions to `Span` methods.
`rustc_middle` is a huge crate and it's always good to move stuff out of it. There are lots of similar methods already on `Span`, so these two functions, `in_external_macro` and `is_from_async_await`, fit right in. The diff is big because `in_external_macro` is used a lot by clippy lints.
r? ``@Noratrieb``
Highlight clarifying information in "expected/found" error
When the expected and found types have the same textual representation, we add clarifying in parentheses. We now visually highlight it in the output.
Detect a corner case where the clarifying information would be the same for both types and skip it, as it doesn't add anything useful.
diagnostics: fix borrowck suggestions for if/while let conditionals
This code detects the case where one of the borrows is inside the let init expr while the other end is not. If that happens, we don't want to suggest adding a semicolon, because it won't work.
Fixes#133941
Clean up MonoItem::instantiation_mode
More progress on cleaning up and documenting instantiation mode selection.
This should have no behavior changes at all, it just rearranges the code inside `MonoItem::instantiation_mode` to a more logical flow and I've tried to explain every choice the implementation is making.
