It's described as a "backwards compatibility hack to keep the diff
small". Removing it requires only a modest amount of churn, and the
resulting code is clearer without the invisible derefs.
Ensure that static initializers are acyclic for NVPTX
NVPTX does not support cycles in static initializers (see rust-lang/rust#146787). LLVM produces an error when attempting to generate code for such constructs, like self-referential structs.
To avoid LLVM UB, we emit a post-monomorphization error on the Rust side before reaching codegen.
This is achieved by analyzing a subgraph of the "mono item graph" that only contains statics.
1. Calculate the strongly connected components (SCCs) of the graph.
2. Check for cycles (more than one node in an SCC or one node that references itself).
NVPTX does not support cycles in static initializers. LLVM produces an error when attempting to codegen such constructs (like self referential structs).
To not produce LLVM UB we instead emit a post-monomorphization error on
Rust side before reaching codegen.
This is achieved by analysing a subgraph of the "mono item graph" that
only contains statics:
1. Calculate the strongly connected components (SCCs) of the graph
2. Check for cycles (more than one node in a SCC or exactly one node
which references itself)
The amdgpu target uses vector types in various places. The vector types
can be used on all architectures, there is no associated target feature
that needs to be enabled.
The largest vector type found in LLVM intrinsics is `v32i32`
(`[32 x i32]`) for mfma intrinsics. Note that while this intrinsic is
only supported on some architectures, the vector type itself is
supported on all architectures.
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
rename erase_regions to erase_and_anonymize_regions
I find it consistently confusing that `erase_regions` does more than replacing regions with `'erased`. it also makes some code look real goofy to be writing manual folders to erase regions with a comment saying "we cant use erase regions" :> or code that re-calls erase_regions on types with regions already erased just to anonymize all the bound regions.
r? lcnr
idk how i feel about the name being almost twice as long now
Fix tail calls to `#[track_caller]` functions
We want `#[track_caller]` to be semver independent, i.e. it should not be a breaking change to add or remove it. Since it changes ABI of a function (adding an additional argument) we have to be careful to preserve this property when adding tail calls.
The only way to achieve this that I can see is:
- we forbid tail calls in functions which are marked with `#[track_caller]` (already implemented)
- tail-calling a `#[track_caller]` marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr)
Ideally the downgrade would be performed by a MIR pass, but that requires post mono MIR opts (cc ```@saethlin,``` rust-lang/rust#131650). For now I've changed code in cg_ssa to accomodate this behaviour (+ added a hack to mono collector so that the shim is actually generated)
Additionally I added a lint, although I don't think it's strictly necessary.
Alternative to rust-lang/rust#144762 (and thus closesrust-lang/rust#144762)
Fixes https://github.com/rust-lang/rust/issues/144755
Ensure we codegen the main fn
This fixes two bugs. The one that was identified in the linked issue is that when we have a `main` function, mono collection didn't consider it as an extra collection root.
The other is that since CGU partitioning doesn't know about the call edges between the entrypoint functions, naively it can put them in different CGUs and mark them all as internal. Which would result in LLVM just deleting all of them. There was an existing hack to exclude `lang = "start"` from internalization, which I've extended to include `main`.
Fixes https://github.com/rust-lang/rust/issues/144052
Insert checks for enum discriminants when debug assertions are enabled
Similar to the existing null-pointer and alignment checks, this checks for valid enum discriminants on creation of enums through unsafe transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
r? `@saethlin`
Stop collecting unmentioned constants
This avoids generating useless dead LLVM IR. This appears to have regressed and/or been introduced in rust-lang/rust#53821 (unfortunately a very large PR - I don't see any direct discussion there of this particular change), but as far as I can tell is at least no longer necessary -- or we lack test coverage -- because none of our UI tests indicate diagnostics regressions. The adjusted codegen-units test has comments explicitly noting that these items should *not* be collected ("These are not referenced, so they do not produce mono-items").
I noticed this while looking at libcore LLVM IR we generate, which contained dead code references to the NOOP Waker item, which is never used inside libcore. Producing LLVM IR for it during libcore's compilation, only for that IR to get deleted by LLVM as unused, isn't useful. Note that the IR is generally all marked internal, too.
Similar to the existing nullpointer and alignment checks, this checks
for valid enum discriminants on creation of enums through unsafe
transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly
sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid
construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for
keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
Since 122662 this no longer gets used in vtables, so we're safe to fully
drop generating these empty functions. Those are eventually cleaned up
by LLVM, but it's wasteful to produce them in the first place.
This also adds a missing test for fn-ptr casts, which do still need to
generate no-op drop glue. It's possible a future optimization could
point all of those at the same drop glue (e.g., for *mut ()) rather than
for each separate type, but that would require extra work for CFI and
isn't particularly easy to do anyway.
Limit the size of cgu names when using the `-Zhuman-readable-cgu-name…
…s` option
Prior to this change, cgu names could be generated which would result in filenames longer than the limit imposed by the OS.
