cg_llvm: Replace enum `MetadataType` with a list of `MetadataKindId` constants
The metadata kind ID values declared in `MetadataType` are not part of the LLVM-C API, and are not machine-checked. If a value that we use ever goes out of sync with LLVM, the resulting bugs could be difficult to track down. And the existing values lack any clear indication of what LLVM declarations they correspond to.
On top of that, we currently have another way of expressing metadata kind IDs in the form of `MetadataKindId`, which creates confusing inconsistency in LLVM bindings.
This PR therefore consolidates all usage of “fixed” metadata kind IDs into one list of `MetadataKindId` constants, which is backed by static assertions in our C++ code that match them up with named anonymous-enum variants in `llvm::LLVMContext`.
Rename various "concrete opaque type" things to say "hidden type"
r? lcnr
I've found "concrete opaque type" terminology to be somewhat confusing as in conversation and when explaining opaque type stuff to people I always just talk about things in terms of hidden types. Also the hidden types of opaques are very much not *concrete* in the same sense that a type without any generic parameters is concrete which is an unfortunate overlap in terminology.
I've tried to update comments to also stop referring to things as concrete opaque types but this is mostly best effort as it difficult to find all such cases amongst the massive amounts of uses of "concrete" or "hidden" across the whole compiler.
cmse: fix 'region variables should not be hashed'
tracking issue: https://github.com/rust-lang/rust/issues/81391
fixes https://github.com/rust-lang/rust/issues/131639
Some background: the `cmse-nonsecure-call` calling convention is used for a call from "secure" to "non-secure" code. To make sure that "non-secure" cannot read any secrets, restrictions are put on the signatures of functions with this calling convention: they can only use 4 arguments for passing arguments, and one register for passing a result. No arguments are passed via the stack, and all other registers are cleared before the call.
We check during `hir_ty_lowering` that the signature follows these rules. We do that by determining and then inspecting the layout of the type. That works well overall, but can run into asserts when the type itself is ill-formed. This PR fixes one such case.
I believe that the fix here, just erasing the regions, is the right shape, but there may be some nuance that I'm missing.
r? types
Point at fn bound that introduced lifetime obligation
The last note is new
```
error[E0597]: `c` does not live long enough
--> $DIR/without-precise-captures-we-are-powerless.rs:19:20
|
LL | fn simple<'a>(x: &'a i32) {
| -- lifetime `'a` defined here
...
LL | let c = async move || { println!("{}", *x); };
| - binding `c` declared here
LL | outlives::<'a>(c());
| ---------------^---
| | |
| | borrowed value does not live long enough
| argument requires that `c` is borrowed for `'a`
LL | outlives::<'a>(call_once(c));
LL | }
| - `c` dropped here while still borrowed
|
note: requirement that `c` is borrowed for `'a` introduced here
--> $DIR/without-precise-captures-we-are-powerless.rs:7:33
|
LL | fn outlives<'a>(_: impl Sized + 'a) {}
| ^^
```
When encountering a `ConstraintCategory::Predicate` in a funtion call, point at the `Span` for that `Predicate` to explain where the lifetime obligation originates from.
CC rust-lang/rust#55307.
Make replacement suggestion `_` in type verbose
```
error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types
--> $DIR/in-signature.rs:6:21
|
LL | fn arr_fn() -> [u8; _] {
| ^ not allowed in type signatures
|
help: replace with the correct return type
|
LL - fn arr_fn() -> [u8; _] {
LL + fn arr_fn() -> [u8; 3] {
|
```
Skip cleanups on unsupported targets
This commit is an update to the `AbortUnwindingCalls` MIR pass in the compiler. Specifically a new boolean is added for "can this target possibly unwind" and if that's `false` then terminators are all adjusted to be unreachable/not present. The end result is that this fixesrust-lang/rust#140293 for wasm targets.
The motivation for this PR is that currently on WebAssembly targets the usage of the `C-unwind` ABI can lead LLVM to either (a) emit exception-handling instructions or (b) hit a LLVM-ICE-style codegen error. WebAssembly as a base instruction set does not support unwinding at all, and a later proposal to WebAssembly, the exception-handling proposal, was what enabled this. This means that the current intent of WebAssembly targets is that they maintain the baseline of "don't emit exception-handling instructions unless enabled". The commit here is intended to restore this behavior by skipping these instructions even when `C-unwind` is present.
Exception-handling is a relatively tricky and also murky topic in WebAssembly, however. There are two sets of instructions LLVM can emit for WebAssembly exceptions, Rust's Emscripten target supports exceptions, WASI targets do not, the LLVM flags to enable this are not always obvious, and additionally this all touches on "changing exception-handling behavior should be a target-level concern, not a feature". Effectively WebAssembly's exception-handling integration into Rust is not finalized at this time. The best idea at this time is that a parallel set of targets will eventually be added which support exceptions, but it's not clear if/when to do this. In the meantime the goal is to keep existing targets working while still enabling experimentation with exception-handling with `-Zbuild-std` and various permutations of LLVM flags.
To that extent this commit does not blanket disable these landing pads and cleanup routines for WebAssembly but instead checks to see if panic=unwind is enabled or if `+exception-handling` is enabled. Tests are updated here as well to account for this where, by default, using a `C-unwind` ABI won't affect Rust codegen at all. If `+exception-handling` is enabled, however, then Rust codegen will look like native platforms where exceptions are caught and the program aborts. More-or-less I've done my best to keep exceptions working on wasm where it's possible to have them work, but turned them off where they're not supposed to be emitted.
Closesrust-lang/rust#140293
Emit allocator attributes for allocator shim
This emits the same attributes we place on allocator declarations on the definitions in the allocator shim as well. This complements https://github.com/rust-lang/rust/pull/146766, which added the attribute for `#[global_allocator]` definitions. Emitting the attributes on the definitions ensures that they cannot be lost of the allocator shim participates in LTO.
See https://github.com/rust-lang/rust/issues/145995 for context, though that one was about `#[global_allocator]`. I'm not sure whether this can occur with the allocator shim as well or not, but better safe than sorry.
I'm not sure whether there is any good way to test this, as the allocator shim is not part of `--emit=llvm-ir`. I've verified this locally by inspecting the bitcode produced by `-C save-temps`.
r? ``@bjorn3``
mbe: macro_check: Fix function comments referencing non-existent parameters
Several functions had comments referencing a non-existent `valid`
parameter. Remove those. The `guar` parameter that handles errors is
already documented.
In the process, remove another duplicate reference to an
already-documented parameter (`binders`).
debuginfo: add an unstable flag to write split DWARF to an explicit directory
Bazel requires knowledge of outputs from actions at analysis time, including file or directory name. In order to work around the lack of predictable output name for dwo files, we group the dwo files in a subdirectory of --out-dir as a post-processing step before returning control to bazel. Unfortunately some debugging workflows rely on directly opening the dwo file rather than loading the merged dwp file, and our trick of moving the files breaks those users. We can't just hardlink the file or copy it, because with remote build execution we wouldn't end up with the un-moved file copied back to the developer's workstation. As a fix, we add this unstable flag that causes dwo files to be written to a build-system-controllable location, which then lets bazel hoover up the dwo files, but the objects also have the correct path for the dwo files.
r? `@davidtwco`
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146653 (improve diagnostics for empty attributes)
- rust-lang/rust#146987 (impl Ord for params and use unstable sort)
- rust-lang/rust#147101 (Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library )
- rust-lang/rust#147123 (Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`)
- rust-lang/rust#147149 (add joboet to library review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`
Tracking issue: https://github.com/rust-lang/rust/issues/43781
The `doc_auto_cfg` and `doc_cfg_hide` features were removed in a recent nightly (by https://github.com/rust-lang/rust/pull/138907).
I believe that the rustc version numbers at which the features were declared to be removed were incorrect, however, and should both be "1.92" (±1). As evidence in favour of this, the error we get from using this was:
```text
error[E0557]: feature has been removed
--> src/lib.rs:22:29
|
22 | #![cfg_attr(docsrs, feature(doc_auto_cfg))]
| ^^^^^^^^^^^^ feature has been removed
|
= note: removed in 1.58.0; see <https://github.com/rust-lang/rust/pull/138907> for more information
= note: merged into `doc_cfg`
```
Note especially the "removed in 1.58" claim. Further evidence is found in the comment further up this file: 4ffeda10e1/compiler/rustc_feature/src/removed.rs (L49-L53)
I've chosen 1.92 as that was the milestone which https://github.com/rust-lang/rust/pull/138907 was added to.
cc `@GuillaumeGomez`
Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library
Now that rust-lang/rust#137122 has landed, we can replace stuff that looks like:
```rust
let a: &[T];
let b: &[T];
let eq = a.len() == b.len() && a.iter().zip(b).all(|(a,b)| a == b)
```
with the much simpler `a.iter().eq(b)`, without losing the perf benefit of the different-length-fast-path.
Also dogfooded `Iterator::eq_by` (cc rust-lang/rust#64295 ) while I'm at it.
First commit (4d1b6fad230f8a5ccceccc7562eadc4ea50059da) should be very straightforward to review, second one (049a4606cb3906787aedf508ee8eea09c2bb3b9a) is slightly more creative, but IMHO a nice cleanup.
impl Ord for params and use unstable sort
AFAICT we are only sorting to find duplicates, so unstable sort should work fine, and maybe is a tiny bit faster?
improve diagnostics for empty attributes
Adds a note about them not having any effect. This was previously done for `feature` attributes but no other attributes. In [converting the `feature` parser](https://github.com/rust-lang/rust/pull/146652) I removed that note. This PR adds it back in and makes it so all attributes benefit from it.
Not blocked on rust-lang/rust#146652, either can merge first
This emits the same attributes we place on allocator declarations
(and allocator definitions using `#[global_allocator]`) on the
definitions in the allocator shim as well, making sure that the
attributes are not lost if the allocator shim participates in LTO.
remove explicit deref of AbiAlign for most methods
Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference.
compiler: remove AbiAlign inside TargetDataLayout
AbiAlign is a thin wrapper around Align, extant mostly because we used to track a separate quasi-notion of alignment that was never a real notion of alignment and removing all of it at once was too churny. This PR maintains AbiAlign usage in public API and most of the compiler, but direct access of these fields for TargetDataLayout is now in terms of Align only.
Detect tuple structs that are unconstructable due to re-export
When a tuple-struct is re-exported that has inaccessible fields at the `use` scope, the type's constructor cannot be accessed through that re-export. We now account for this case and extend the resulting resolution error. We also check if the constructor would be accessible directly, not through the re-export, and if so, we suggest using the full path instead.
```
error[E0423]: cannot initialize a tuple struct which contains private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:12:33
|
LL | let crate::Foo(x) = crate::Foo(42);
| ^^^^^^^^^^
|
note: the type is accessed through this re-export, but the type's constructor is not visible in this import's scope due to private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:3:9
|
LL | pub use my_mod::Foo;
| ^^^^^^^^^^^
help: the type can be constructed directly, because its fields are available from the current scope
|
LL | let crate::Foo(x) = crate::my_mod::Foo(42);
| ~~~~~~~~~~~~~~~~~~
```
Fix#133343.
Much of the compiler calls functions on Align projected from AbiAlign.
AbiAlign impls Deref to its inner Align, so we can simplify these away.
Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq,
as those have odd inference.
When a tuple-struct is re-exported that has inaccessible fields at the `use` scope, the type's constructor cannot be accessed through that re-export. We now account for this case and extend the resulting resolution error. We also check if the constructor would be accessible directly, not through the re-export, and if so, we suggest using the full path instead.
```
error[E0423]: cannot initialize a tuple struct which contains private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:12:33
|
LL | let crate::Foo(x) = crate::Foo(42);
| ^^^^^^^^^^
|
note: the type is accessed through this re-export, but the type's constructor is not visible in this import's scope due to private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:3:9
|
LL | pub use my_mod::Foo;
| ^^^^^^^^^^^
help: the type can be constructed directly, because its fields are available from the current scope
|
LL | let crate::Foo(x) = crate::my_mod::Foo(42);
| ~~~~~~~~~~~~~~~~~~
```
Fix#133343.
```
error[E0716]: temporary value dropped while borrowed
--> $DIR/multiple-sources-for-outlives-requirement.rs:5:38
|
LL | fn foo<'b>() {
| -- lifetime `'b` defined here
LL | outlives_indir::<'_, 'b, _>(&mut 1u32);
| ---------------------------------^^^^-- temporary value is freed at the end of this statement
| | |
| | creates a temporary value which is freed while still in use
| argument requires that borrow lasts for `'b`
|
note: requirements that the value outlives `'b` introduced here
--> $DIR/multiple-sources-for-outlives-requirement.rs:1:23
|
LL | fn outlives_indir<'a: 'b, 'b, T: 'a>(_x: T) {}
| ^^ ^^
```
```
error[E0597]: `c` does not live long enough
--> $DIR/without-precise-captures-we-are-powerless.rs:19:20
|
LL | fn simple<'a>(x: &'a i32) {
| -- lifetime `'a` defined here
...
LL | let c = async move || { println!("{}", *x); };
| - binding `c` declared here
LL | outlives::<'a>(c());
| ---------------^---
| | |
| | borrowed value does not live long enough
| argument requires that `c` is borrowed for `'a`
LL | outlives::<'a>(call_once(c));
LL | }
| - `c` dropped here while still borrowed
|
note: requirement that `c` is borrowed for `'a` introduced here
--> $DIR/without-precise-captures-we-are-powerless.rs:7:33
|
LL | fn outlives<'a>(_: impl Sized + 'a) {}
| ^^
```
When encountering a `ConstraintCategory::Predicate` in a funtion call, point at the `Span` for that `Predicate` to explain where the lifetime obligation originates from.
Reland "Add LSX accelerated implementation for source file analysis"
This patch introduces an LSX-optimized version of `analyze_source_file` for the `loongarch64` target. Similar to existing SSE2 implementation for x86, this version:
- Processes 16-byte chunks at a time using LSX vector intrinsics.
- Quickly identifies newlines in ASCII-only chunks.
- Falls back to the generic implementation when multi-byte UTF-8 characters are detected or in the tail portion.
Reland rust-lang/rust#145963
r? ``@lqd``
Allow `&raw [mut | const]` for union field in safe code
fixesrust-lang/rust#141264
r? ``@Veykril``
Unresolved questions:
- [x] Any edge cases?
- [x] How this works with rust-analyzer (because all I've did is prevent compiler from emitting error in `&raw` context) (rust-lang/rust-analyzer#19867)
- [x] Should we allow `addr_of!` and `addr_of_mut!` as well? In current version they both (`&raw` and `addr_of!`) are allowed (They are the same)
- [x] Is chain of union fields is a safe? (Yes)
fix rebasing cycle heads when not reaching a fixpoint
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/232
annoyingly subtle, imagine the following proof tree
- A (no cycle head usages, final result Y)
- *ignored* B (depends on A with provisional result X)
- A (cycle, provisional result X)
- B (using the cache entry here incorrectly assumes A has final result X)
r? ``@BoxyUwU``
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 5)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#146673
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
Some of these are a little more complex than most of the previous migrations, because they split one LLVMRust binding into multiple LLVM bindings, but nothing too fancy.
This appears to be the last of the low-hanging fruit. As noted in https://github.com/rust-lang/rust/issues/134001#issuecomment-2524979268, the remaining bindings are difficult or impossible to migrate at present.
