Comment out unused error codes and add description for E0316
I have added an extended description of `E0316` and commented out a bunch of unused error codes to make clear the fact that they are no longer in use. You can check for yourself with
```shell
for ec in \
E0314 E0315 E0473 E0474 E0475 E0479 E0480 E0481 \
E0483 E0484 E0485 E0486 E0487 E0488 E0489
do
if [ ! -z "`grep -r $ec compiler/* --exclude-dir=rustc_error_codes`" ]
then
echo $ec
false
fi
done
```
i.e. these error codes appear nowhere in the compiler code and thus cannot be emitted.
r? ```@GuillaumeGomez```
Currently, we only point at the span of the macro argument. When the
macro call is itself generated by another macro, this can make it
difficult or impossible to determine which macro is responsible for
producing the error.
This commit fixes an issue not found during #84988 where rustdoc is used
to document cross-platform intrinsics but it was requiring that
functions which use `#[target_feature]` are `unsafe` erroneously, even
if they're WebAssembly specific. Rustdoc today, for example, already has
a special case where it enables annotations like
`#[target_feature(enable = "simd128")]` on platforms other than
WebAssembly. The purpose of this commit is to relax the "require all
`#[target_feature]` functions are `unsafe`" requirement for all targets
whenever rustdoc is running, enabling all targets to fully document
other targets, such as WebAssembly, where intrinsics functions aren't
always `unsafe`.
Remove the install prefix from the rpath set when using -Crpath
It was broken anyway for rustup installs and nobody seems to have noticed.
Fixes https://github.com/rust-lang/rust/issues/82392
Unify duplicate linker_and_flavor methods in rustc_codegen_{cranelift,ssa}.
The two methods were exactly the same so this removes the cranelift copy. This will help make sure both they don't get out of sync.
Fix ICE during type layout when there's a `[type error]`
Fixes#84108.
Based on estebank's [comment], except I used `delay_span_bug` because it
should work in more cases, and I think it expresses its intent more
clearly.
r? `@estebank`
[comment]: https://github.com/rust-lang/rust/issues/84108#issuecomment-818916848
Driver improvements
This PR contains a couple of cleanups for the driver and a few small improvements for the custom codegen backend interface. It also implements `--version` and `-Cpasses=list` support for custom codegen backends.
Fix corrected example in E0759.md
This pull request fixes#86061, which was probably caused by a copy-paste error, where the supposedly corrected code example was also marked with `compile_fail`. Thus, the fact that the "correct" example actually _isn't_ correct was not caught by the doc-tests. This pull request removes the incorrect `compile_fail` annotation and fixes the example.
r? ``@GuillaumeGomez``
Fix two ICEs in the parser
This pull request fixes#84104 and fixes#84148. The latter is caused by an invalid `assert_ne!()` in the parser, which I have simply removed because the error is then caught in another part of the parser.
#84104 is somewhat more subtle and has to do with a suggestion to remove extraneous `<` characters; for instance:
```rust
fn main() {
foo::<Ty<<<i32>();
}
```
currently leads to
```
error: unmatched angle brackets
--> unmatched-langle.rs:2:10
|
2 | foo::<Ty<<<i32>();
| ^^^ help: remove extra angle brackets
```
which is obviously wrong and stems from the fact that the code for issuing the above suggestion does not consider the possibility that there might be other tokens in between the opening angle brackets. In #84104, this has led to a span being generated that ends in the middle of a multi-byte character (because the code issuing the suggestion thought that it was only skipping over `<`, which are single-byte), causing an ICE.
Add variance-related information to lifetime error messages
This PR adds a basic framework for displaying variance-related information in error messages. For example:
```
error: lifetime may not live long enough
--> $DIR/type-check-pointer-comparisons.rs:12:5
|
LL | fn compare_mut<'a, 'b>(x: *mut &'a i32, y: *mut &'b i32) {
| -- -- lifetime `'b` defined here
| |
| lifetime `'a` defined here
LL | x == y;
| ^ requires that `'a` must outlive `'b`
|
= help: consider adding the following bound: `'a: 'b`
= note: requirement occurs because of a mutable pointer to &i32
= note: mutable pointers are invariant over their type parameter
= help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance
```
The last three lines are new.
This is accomplished by adding a new struct `VarianceDiagInfo`, and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`), we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error, we use the `VarianceDiagInfo` to add additional information to the error message.
This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore, the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs.
Limitations:
* We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice', our variance will never change again after it becomes invariant. Handling contravariance would be trickier, since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments, we can probably get away without a very fancy message for cases involving contravariance.
* `VarianceDiagInfo` currently only handles mutable pointers/references. However, user-defined types (structs, enums, and unions) have the variance of their type parameters inferred, so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred.
* The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon, then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.
linker: Reorder linker arguments
- Split arguments into order-independent and order-dependent, to define more precisely what (pre-,post-,late-,)link-args mean.
- Add some comments.
- Combine all native library arguments together, to simplify potential support for library deduplication and similar things
- Split arguments into order-independent and order-dependent, to define more precisely what (pre,post,late)-link-args mean
parser: Ensure that all nonterminals have tokens after parsing
`parse_nonterminal` should always result in something with tokens.
This requirement wasn't satisfied in two cases:
- `stmt` nonterminal with expression statements (e.g. `0`, or `{}`, or `path + 1`) because `fn parse_stmt_without_recovery` forgot to propagate `force_collect` in some cases.
- `expr` nonterminal with expressions with built-in attributes (e.g. `#[allow(warnings)] 0`) due to an incorrect optimization in `fn parse_expr_force_collect`, it assumed that all expressions starting with `#` have their tokens collected during parsing, but that's not true if all the attributes on that expression are built-in and inert.
(Discovered when trying to implement eager `cfg` expansion for all attributes https://github.com/rust-lang/rust/pull/83824#issuecomment-817317170.)
r? `@Aaron1011`
Drop an `if let` that will always succeed
We've already checked that `proj_base == []` in the line above and renaming
`place_local` to `local` doesn't gain us anything.
``@rustbot`` modify labels +C-cleanup +T-compiler
Tweak wasm_base target spec to indicate linker is not GNU and update linker inferring logic for wasm-ld.
Reported via [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/wasi.20linker.20unknown.20argument.3A.20--as-needed): we try passing `--as-needed` to the linker if it's GNU ld which `wasm-ld` is not. Usually this isn't an issue for wasm as we would use the WasmLd linker driver but because the linker in question (`wasm32-unknown-wasi-wasm-ld`) ended with `-ld` our linker inferring [logic](f64503eb55/compiler/rustc_codegen_ssa/src/back/link.rs (L957-L1040)) used the `GccLinker` implementations. (UPD: The linker inferring logic actually didn't apply in this case because the linker is actually invoked through gcc in the reported issue. But it's still worth updating the logic I think.)
This change then has 2 parts:
1. Update wasm_base target spec to indicate `linker_is_gnu: false` plus a few additions of `target.is_like_wasm` to handle flags `wasm-ld` does in fact support.
2. Improve the linker detection logic to properly determine the correct flavor of wasm linker we're using when we can.
We need to add the new `target.is_like_wasm` branches to handle the case where the "linker" used could be something like clang which would then under the hood call wasm-ld.
Preserve metadata w/ Solaris-like linkers.
#84468 moved the `-zignore` linker flag from the `gc_sections` method to `add_as_needed` which is more accurate but Solaris-style linkers will also end up removing an unreferenced ELF sections [1]. This had the unfortunate side effect of causing the `.rustc` section (which has the metada) to be removed which could cause issues when trying to link against the resulting crates or use proc macros.
Since the `-zignore` is positional, we fix this by moving the metadata objects to before the flag.
[1] Specifically a section is considered unreferenced if:
* The section is allocatable
* No other sections bind to (relocate) to this section
* The section provides no global symbols
https://docs.oracle.com/cd/E19683-01/817-3677/6mj8mbtbs/index.html#chapter4-19
Show test type during prints
Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run.
During #83857 I got the feedback that test output can be confusing.
For the moment test output is
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) ... ok
test $DIR/test-type.rs - f (line 21) ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
I propose to change output by indicating the test type as
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) - compile ... ok
test $DIR/test-type.rs - f (line 21) - compile fail ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...".
------------
Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
Partial support for raw-dylib linkage
First cut of functionality for issue #58713: add support for `#[link(kind = "raw-dylib")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions, or the `#[link_ordinal]` attribute, or `#[link(kind = "raw-dylib")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern "stdcall"` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR.
This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.
BPF target support
This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.
I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
Remove special handling of `box_free` from `LocalAnalyzer`
The special casing of `box_free` predates the use of dominators in
analyzer. It is no longer necessary now that analyzer verifies that
the first assignment dominates all uses.
This addresses a codegen-issue that needs to be fixed upstream in LLVM.
While we wait for the fix, we can disable it.
Verified manually that the outliner is no longer run when
`-Copt-level=z` is specified, and also that you can override this with
`-Cllvm-args=-enable-machine-outliner` if you need it anyway.
A regression test is not really feasible in this instance, given that we
do not have any minimal reproducers.
Fixes#85351
Allow raw pointers in SIMD types
Closes#85915 by loosening the strictness in typechecking and adding a test to guarantee it passes.
This still might be too strict, as references currently do pass monomorphization, but my understanding is that they are not guaranteed to be "scalar" in the same way.
Remove `doc(include)`
This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539, but technically it was for deprecating, not removing the feature altogether.
This should not be merged before #83366.
cc `@petrochenkov`
Implement DepTrackingHash for `Option` through blanket impls instead of macros
This avoids having to add a new macro call for both the `Option` and the type itself.
Noticed this while working on https://github.com/rust-lang/rust/pull/84233.
r? `@Aaron1011`
This does not yet support #[link_name] attributes on functions, the #[link_ordinal]
attribute, #[link(kind = "raw-dylib")] on extern blocks in bin crates, or
stdcall functions on 32-bit x86.
don't suggest unsized indirection in where-clauses
Skip where-clauses when suggesting using indirection in combination with
`?Sized` bounds on type parameters.
Fixes#85943.
`@estebank` I think this doesn't conflict with your work in #85947; please let me know if you'd like me to cherry pick it to a new branch based on yours instead.
wasm: Make simd types passed via indirection again
This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
rustc: Store metadata-in-rlibs in object files
This commit updates how rustc compiler metadata is stored in rlibs.
Previously metadata was stored as a raw file that has the same format as
`--emit metadata`. After this commit, however, the metadata is encoded
into a small object file which has one section which is the contents of
the metadata.
The motivation for this commit is to fix a common case where #83730
arises. The problem is that when rustc crates a `dylib` crate type it
needs to include entire rlib files into the dylib, so it passes
`--whole-archive` (or the equivalent) to the linker. The problem with
this, though, is that the linker will attempt to read all files in the
archive. If the metadata file were left as-is (today) then the linker
would generate an error saying it can't read the file. The previous
solution was to alter the rlib just before linking, creating a new
archive in a temporary directory which has the metadata file removed.
This problem from before this commit is now removed if the metadata file
is stored in an object file that the linker can read. The only caveat we
have to take care of is to ensure that the linker never actually
includes the contents of the object file into the final output. We apply
similar tricks as the `.llvmbc` bytecode sections to do this.
This involved changing the metadata loading code a bit, namely updating
some of the LLVM C APIs used to use non-deprecated ones and fiddling
with the lifetimes a bit to get everything to work out. Otherwise though
this isn't intended to be a functional change really, only that metadata
is stored differently in archives now.
This should end up fixing #83730 because by default dylibs will no
longer have their rlib dependencies "altered" meaning that
split-debuginfo will continue to have valid paths pointing at the
original rlibs. (note that we still "alter" rlibs if LTO is enabled to
remove Rust object files and we also "alter" for the #[link(cfg)]
feature, but that's rarely used).
Closes#83730
This commit updates how rustc compiler metadata is stored in rlibs.
Previously metadata was stored as a raw file that has the same format as
`--emit metadata`. After this commit, however, the metadata is encoded
into a small object file which has one section which is the contents of
the metadata.
The motivation for this commit is to fix a common case where #83730
arises. The problem is that when rustc crates a `dylib` crate type it
needs to include entire rlib files into the dylib, so it passes
`--whole-archive` (or the equivalent) to the linker. The problem with
this, though, is that the linker will attempt to read all files in the
archive. If the metadata file were left as-is (today) then the linker
would generate an error saying it can't read the file. The previous
solution was to alter the rlib just before linking, creating a new
archive in a temporary directory which has the metadata file removed.
This problem from before this commit is now removed if the metadata file
is stored in an object file that the linker can read. The only caveat we
have to take care of is to ensure that the linker never actually
includes the contents of the object file into the final output. We apply
similar tricks as the `.llvmbc` bytecode sections to do this.
This involved changing the metadata loading code a bit, namely updating
some of the LLVM C APIs used to use non-deprecated ones and fiddling
with the lifetimes a bit to get everything to work out. Otherwise though
this isn't intended to be a functional change really, only that metadata
is stored differently in archives now.
This should end up fixing #83730 because by default dylibs will no
longer have their rlib dependencies "altered" meaning that
split-debuginfo will continue to have valid paths pointing at the
original rlibs. (note that we still "alter" rlibs if LTO is enabled to
remove Rust object files and we also "alter" for the #[link(cfg)]
feature, but that's rarely used).
Closes#83730
Support for force-warns
Implements https://github.com/rust-lang/rust/issues/85512.
This PR adds a new command line option `force-warns` which will force the provided lints to warn even if they are allowed by some other mechanism such as `#![allow(warnings)]`.
Some remaining issues:
* https://github.com/rust-lang/rust/issues/85512 mentions that `force-warns` should also be capable of taking lint groups instead of individual lints. This is not implemented.
* If a lint has a higher warning level than `warn`, this will cause that lint to warn instead. We probably want to allow the lint to error if it is set to a higher lint and is not allowed somewhere else.
* One test is currently ignored because it's not working - when a deny-by-default lint is allowed, it does not currently warn under `force-warns`. I'm not sure why, but I wanted to get this in before the weekend.
r? `@nikomatsakis`
For extern providers, both provide and provide_extern are called.
wasm_import_module_map is already provided in provide, so it doesn't
need to be provided in provide_extern.
Reland - Report coverage `0` of dead blocks
Fixes: #84018
With `-Z instrument-coverage`, coverage reporting of dead blocks
(for example, blocks dropped because a conditional branch is dropped,
based on const evaluation) is now supported.
Note, this PR relands an earlier, reverted PR that failed when compiling
generators. The prior issues with generators has been resolved and a new
test was added to prevent future regressions.
Check out the resulting changes to test coverage of dead blocks in the
test coverage reports in this PR.
r? `@tmandry`
fyi: `@wesleywiser`
Restoring the `num_def_ids` function in the CStore API
## The context
I am the maintainer of https://github.com/hacspec/hacspec, an embedded Rust DSL aimed at cryptographic specifications. As it is normal for an embedded DSL, Hacspec's compiler relies on being plugged to the internal API of the Rust compiler, which is unstable and subject to changes.
## The problem
The Hacspec compiler features its own typechecker, that performs an additional, more restrictive typechecking pass over the Rust code of a crate. To complete this typechecking, the Hacspec compiler needs to retrieve the signature of functions defined in non-local imported crates. Rather than retrieving these signatures on-demand, the Hacspec compiler pre-populates its typechecking context with all the Hacspec-compatible symbols defined in non-local crates first. This requires having a way to iterate over all the definitions in a non-local crate.
I used to do this with `CrateMetadata::all_def_path_hashes_and_def_ids`, but this function was deleted in 908bf5a310. Then, I fellback on `CStore::num_def_ids`, exploiting the fact that all the `DefIds` for a crate have the same `krate_num` and range from `0` to `num_def_ids(krate_num)`. But `num_def_ids` was deleted in b6120bfb35.
I looked to the `Cstore::item_children_untracked` function to replicate the feature of traversing through all the `DefId` for a crate, using `CRATE_DEF_INDEX` as the root, but this does not work as recursive `Cstore::item_children_untracked` calls do not reach all the symbols I was able to reach using the two previous methods.
## Description of this PR
This PR simply restores in the public API of `CStore` the `num_def_ids` function, giving the size of the definition table for a given crate.
Remove unused feature gates
The first commit removes a usage of a feature gate, but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`)
The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though.
The third commit removes (almost) all feature gates from the compiler that weren't used anyway.
This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
Improve debugging experience for enums on windows-msvc
This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways:
1. Improves the debugger experience for directly tagged enums.
2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example, `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger.
3. Significantly improves the debugger experience for niche-layout enums.
Let's look at a few examples:
```rust
pub enum CStyleEnum {
Base = 2,
Exponent = 16,
}
pub enum NicheLayoutEnum {
Tag1,
Data { my_data: CStyleEnum },
Tag2,
Tag3,
Tag4,
}
pub enum OtherEnum<T> {
Case1(T),
Case2(T),
}
fn main() {
let a = Some(CStyleEnum::Base);
let b = Option::<CStyleEnum>::None;
let c = NicheLayoutEnum::Tag1;
let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent };
let e = NicheLayoutEnum::Tag2;
let f = Some(&1u32);
let g = Option::<&'static u32>::None;
let h = Some(&2u64);
let i = Option::<&'static u64>::None;
let j = Some(12u32);
let k = Option::<u32>::None;
let l = Some(12.34f64);
let m = Option::<f64>::None;
let n = CStyleEnum::Base;
let o = CStyleEnum::Exponent;
let p = Some("IAMA optional string!".to_string());
let q = OtherEnum::Case1(42u32);
}
```
This is what WinDbg Preview shows using the latest rustc nightly:
Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse, drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types:
With the changes in this PR, we're able to write two natvis definitions that cover all enum cases generally. After building with these changes, WinDbg now shows this instead:
Drilling into the same variables, we can see much more useful information:
Fixes#84670Fixes#84671
Restored underlying num_def_ids_method
Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs
Changed name to fit with naming convention
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs
Replace regular doc with Rustdoc comment
Co-authored-by: Joshua Nelson <jyn514@gmail.com>
Clarifies third-party use of num_def_ids_untracked
Use pattern matching instead of checking lengths explicitly
This piece of code checks that there are exaclty two variants, one having
exactly one field, the other having exactly zero fields. If any of these
conditions is violated, it returns `None`. Otherwise it assigns that one
field's ty to `field_ty`.
Instead of fiddling with indices and length checks explicitly, use pattern
matching to simplify this.
`@rustbot` modify labels +C-cleanup +T-compiler
Turn off frame pointer elimination on all Apple platforms.
This ends up disabling frame pointer elimination on aarch64_apple_darwin
which matches what clang does by default along with the
aarch64_apple_ios and x86_64_apple_darwin targets.
Further, the Apple docs "Writing ARM64 Code for Apple Platforms" has a section
called "Respect the Purpose of Specific CPU Registers" which
specifically calls out the frame pointer register (x29):
The frame pointer register (x29) must always address a valid frame
record. Some functions — such as leaf functions or tail calls — may
opt not to create an entry in this list As a result, stack traces
are always meaningful, even without debug information.
Other platforms are updated to not override the default.
rustc: Allow safe #[target_feature] on wasm
This commit updates the compiler's handling of the `#[target_feature]`
attribute when applied to functions on WebAssembly-based targets. The
compiler in general requires that any functions with `#[target_feature]`
are marked as `unsafe` as well, but this commit relaxes the restriction
for WebAssembly targets where the attribute can be applied to safe
functions as well.
The reason this is done is that the motivation for this feature of the
compiler is not applicable for WebAssembly targets. In general the
`#[target_feature]` attribute is used to enhance target CPU features
enabled beyond the basic level for the rest of the compilation. If done
improperly this means that your program could execute an instruction
that the CPU you happen to be running on does not understand. This is
considered undefined behavior where it is unknown what will happen (e.g.
it's not a deterministic `SIGILL`).
For WebAssembly, however, the target is different. It is not possible
for a running WebAssembly program to execute an instruction that the
engine does not understand. If this were the case then the program would
not have validated in the first place and would not run at all. Even if
this were allowed in some hypothetical future where engines have some
form of runtime feature detection (which they do not right now) any
implementation of such a feature would generate a trap if a module
attempts to execute an instruction the module does not understand. This
deterministic trap behavior would still not fall into the category of
undefined behavior because the trap is deterministic.
For these reasons the `#[target_feature]` attribute is now allowed on
safe functions, but only for WebAssembly targets. This notably enables
the wasm-SIMD intrinsics proposed for stabilization in #74372 to be
marked as safe generally instead of today where they're all `unsafe` due
to the historical implementation of `#[target_feature]` in the compiler.
This ends up disabling frame pointer elimination on aarch64_apple_darwin
which matches what clang does by default along with the
aarch64_apple_ios and x86_64_apple_darwin targets.
Further, the Apple docs "Writing ARM64 Code for Apple Platforms" has a section
called "Respect the Purpose of Specific CPU Registers" which
specifically calls out the frame pointer register (x29):
The frame pointer register (x29) must always address a valid frame
record. Some functions — such as leaf functions or tail calls — may
opt not to create an entry in this list As a result, stack traces
are always meaningful, even without debug information.
Other platforms are updated to not override the default.
Previously, we would generate a single struct with the layout of the
dataful variant plus an extra field whose name contained the value of
the niche (this would only really work for things like `Option<&_>`
where we can determine that the `None` case maps to `0` but for enums
that have multiple tag only variants, this doesn't work).
Now, we generate a union of two structs, one which is the layout of the
dataful variant and one which just has a way of reading the
discriminant. We also generate an enum which maps the discriminant value
to the tag only variants.
We also encode information about the range of values which correspond to
the dataful variant in the type name and then use natvis to determine
which union field we should display to the user.
As a result of this change, all niche-layout enums render correctly in
WinDbg and Visual Studio!
This wasn't necessary for msvc and caused issues where different types
with the same name such as different instantiations of `Option<T>` would
have colliding debuginfo. This confused the debugger which would pick
one of the type definitions and use for all types with that name even
though they had different layout.
Avoid creating anonymous nodes with zero or one dependency.
Anonymous nodes are only useful to encode dependencies, and cannot be replayed from one compilation session to another.
As such, anonymous nodes without dependency are always green.
Anonymous nodes with only one dependency are equivalent to this dependency.
cc #45408
cc `@michaelwoerister`
This piece of code checks that there are exaclty two variants, one having
exactly one field, the other having exactly zero fields. If any of these
conditions is violated, it returns `None`. Otherwise it assigns that one
field's ty to `field_ty`.
Instead of fiddling with indices and length checks explicitly, use pattern
matching to simplify this.
Fixes: #84018
With `-Z instrument-coverage`, coverage reporting of dead blocks
(for example, blocks dropped because a conditional branch is dropped,
based on const evaluation) is now supported.
Note, this PR relands an earlier, reverted PR that failed when compiling
generators. The prior issues with generators has been resolved and a new
test was added to prevent future regressions.
Check out the resulting changes to test coverage of dead blocks in the
test coverage reports in this PR.
Reduce the amount of untracked state in TyCtxt
Access to untracked global state may generate instances of #84970.
The GlobalCtxt contains the lowered HIR, the resolver outputs and interners.
By wrapping the resolver inside a query, we make sure those accesses are properly tracked.
As a no_hash query, all dependent queries essentially become `eval_always`,
what they should have been from the beginning.
Don't sort a `Vec` before computing its `DepTrackingHash`
Previously, we sorted the vec prior to hashing, making the hash
independent of the original (command-line argument) order. However, the
original vec was still always kept in the original order, so we were
relying on the rest of the compiler always working with it in an
'order-independent' way.
This assumption was not being upheld by the `native_libraries` query -
the order of the entires in its result depends on the order of entries
in `Options.libs`. This lead to an 'unstable fingerprint' ICE when the
`-l` arguments were re-ordered.
This PR removes the sorting logic entirely. Re-ordering command-line
arguments (without adding/removing/changing any arguments) seems like a
really niche use case, and correctly optimizing for it would require
additional work. By always hashing arguments in their original order, we
can entirely avoid a cause of 'unstable fingerprint' errors.
Emit a hard error when a panic occurs during const-eval
Previous, a panic during const evaluation would go through the
`const_err` lint. This PR ensures that such a panic always causes
compilation to fail.
Fix span of redundant generic arguments
Fixes#71563
Above issue is about lifetime arguments, but generic arguments also have same problem.
This PR fixes both help messages.
The special casing of `box_free` predates the use of dominators in
analyzer. It is no longer necessary now that analyzer verifies that
the first assignment dominates all uses.
Use correct edition when parsing `:pat` matchers
As described in issue #85708, we currently do not properly decode
`SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a
result, when we decode a span from a foreign crate with
`SyntaxContext::root()`, we end up up considering it to have the edition
of the *current* crate, instead of the foreign crate where it was
originally created.
A full fix for this issue will be a fairly significant undertaking.
Fortunately, it's possible to implement a partial fix, which gives us
the correct edition-dependent behavior for `:pat` matchers when the
macro is loaded from another crate. Since we have the edition of the
macro's defining crate available, we can 'recover' from seeing a
`SyntaxContext::root()` and use the edition of the macro's defining
crate.
Any solution to issue #85708 must reproduce the behavior of this
targeted fix - properly preserving a foreign `SyntaxContext::root()`
means (among other things) preserving its edition, which by definition
is the edition of the foreign crate itself. Therefore, this fix moves us
closer to the correct overall solution, and does not expose any new
incorrect behavior to macros.
Use command line metadata path if provided
If the command-line has `--emit metadata=some/path/libfoo.rmeta` then
use that.
Closes#85356
I couldn't find any existing tests for the `--emit TYPE=PATH` command line syntax, so I wasn't sure how to test this aside from ad-hoc manual testing. Is there a ui test type for "generated output file with expected name"?
Merge CrateDisambiguator into StableCrateId
This simplifies the code and potentially improves performance by reducing the amount of hashed data.
Fixes https://github.com/rust-lang/rust/issues/85795
Make `Step` trait safe to implement
This PR makes a few modifications to the `Step` trait that I believe better position it for stabilization in the short term. In particular,
1. `unsafe trait TrustedStep` is introduced, indicating that the implementation of `Step` for a given type upholds all stated invariants (which have remained unchanged). This is gated behind a new `trusted_step` feature, as stabilization is realistically blocked on min_specialization.
2. The `Step` trait is internally specialized on the `TrustedStep` trait, which avoids a serious performance regression.
3. `TrustedLen` is implemented for `T: TrustedStep` as the latter's invariants subsume the former's.
4. The `Step` trait is no longer `unsafe`, as the invariants must not be relied upon by unsafe code (unless the type implements `TrustedStep`).
5. `TrustedStep` is implemented for all types that implement `Step` in the standard library and compiler.
6. The `step_trait_ext` feature is merged into the `step_trait` feature. I was unable to find any reasoning for the features being split; the `_unchecked` methods need not necessarily be stabilized at the same time, but I think it is useful to have them under the same feature flag.
All existing implementations of `Step` will be broken, as it is not possible to `unsafe impl` a safe trait. Given this trait only exists on nightly, I feel this breakage is acceptable. The blanket `impl<T: Step> TrustedLen for T` will likely cause some minor breakage, but this should be covered by the equivalent impl for `TrustedStep`.
Hopefully these changes are sufficient to place `Step` in decent position for stabilization, which would allow user-defined types to be used with `a..b` syntax.
Don't panic when failing to initialize incremental directory.
This removes a panic when rustc fails to initialize the incremental directory. This can commonly happen on various filesystems that don't support locking (often various network filesystems). Panics can be confusing and scary, and there are already plenty of issues reporting this.
This has been panicking since 1.22 due to I think #44502 which was a major rework of how things work. Previously, things were simpler and the [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.21.0/src/librustc_incremental/persist/load.rs#L43-L65) function would emit an error and then continue on without panicking. With 1.22, [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.22.0/src/librustc_incremental/persist/load.rs#L44) was changed so that it assumes it can load the data without errors. Today, the problem is that it calls [`prepare_session_directory`](fbf1b1a719/compiler/rustc_interface/src/passes.rs (L175-L179)) and then immediately calls `garbage_collect_session_directories` which will panic since the session is `IncrCompSession::NotInitialized`.
The solution here is to have `prepare_session_directory` return an error that must be handled so that compilation stops if it fails.
Some other options:
* Ignore directory lock failures.
* Print a warning on directory lock failure, but otherwise continue with incremental enabled.
* Print a warning on directory lock failure, and disable incremental.
* Provide a different locking mechanism.
Cargo ignores lock errors if locking is not supported, so that would be a precedent for the first option. These options would require quite a bit more changes, but I'm happy to entertain any of them, as I think they all have valid justifications.
There is more discussion on the many issues where this is reported: #49773, #59224, #66513, #76251. I'm not sure if this can be considered closing any of those, though, since I think there is some value in discussing if there is a way to avoid the error altogether. But I think it would make sense to at least close all but one to consolidate them.
As described in issue #85708, we currently do not properly decode
`SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a
result, when we decode a span from a foreign crate with
`SyntaxContext::root()`, we end up up considering it to have the edition
of the *current* crate, instead of the foreign crate where it was
originally created.
A full fix for this issue will be a fairly significant undertaking.
Fortunately, it's possible to implement a partial fix, which gives us
the correct edition-dependent behavior for `:pat` matchers when the
macro is loaded from another crate. Since we have the edition of the
macro's defining crate available, we can 'recover' from seeing a
`SyntaxContext::root()` and use the edition of the macro's defining
crate.
Any solution to issue #85708 must reproduce the behavior of this
targeted fix - properly preserving a foreign `SyntaxContext::root()`
means (among other things) preserving its edition, which by definition
is the edition of the foreign crate itself. Therefore, this fix moves us
closer to the correct overall solution, and does not expose any new
incorrect behavior to macros.
A bit more polish on const eval errors
This PR adds a bit more polish to the const eval errors:
- a slight improvement to the PME messages from #85633: I mentioned there that the erroneous item's paths were dependent on the environment, and could be displayed fully qualified or not. This can obscure the items when they come from a dependency. This PR uses the pretty-printing code ensuring the items' paths are not trimmed.
- whenever there are generics involved in an item where const evaluation errors out, the error message now displays the instance and its const arguments, so that we can see which instantiated item and compile-time values lead to the error.
So we get this slight improvement for our beloved `stdarch` example, on nightly:
```
error[E0080]: evaluation of constant value failed
--> ./stdarch/crates/core_arch/src/macros.rs:8:9
|
8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', /rustc/9111b8ae9793f18179a1336417618fc07a9cac85/library/core/src/../../stdarch/crates/core_arch/src/macros.rs:8:9
|
```
to this PR's:
```
error[E0080]: evaluation of `core::core_arch::macros::ValidateConstImm::<51_i32, 0_i32, 15_i32>::VALID` failed
--> ./stdarch/crates/core_arch/src/macros.rs:8:9
|
8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9
|
```
with this PR.
Of course this is an idea from Oli, so maybe r? `@oli-obk` if they have the time.
