Strengthen validation of FFI attributes
Previously, `codegen_attrs` validated the attributes `#[ffi_pure]`, `#[ffi_const]`, and `#[ffi_returns_twice]` to make sure that they were only used on foreign functions. However, this validation was insufficient in two ways:
1. `codegen_attrs` only sees items for which code must be generated, so it was unable to raise errors when the attribute was incorrectly applied to macros and the like.
2. the validation code only checked that the item with the attr was foreign, but not that it was a foreign function, allowing these attributes to be applied to foreign statics as well.
This PR moves the validation to `check_attr`, which sees all items. It additionally changes the validation to ensure that the attribute's target is `Target::ForeignFunction`, only allowing the attributes on foreign functions and not foreign statics. Because these attributes are unstable, there is no risk for backwards compatibility. The changes also ending up making the code much easier to read.
This PR is best reviewed commit by commit. Additionally, I was considering moving the tests to the `attribute` subdirectory, to get them out of the general UI directory. I could do that as part of this PR or a follow-up, as the reviewer prefers.
CC: #58328, #58329
Rollup of 8 pull requests
Successful merges:
- #106618 (Disable `linux_ext` in wasm32 and fortanix rustdoc builds.)
- #107097 (Fix def-use dominance check)
- #107154 (library/std/sys_common: Define MIN_ALIGN for m68k-unknown-linux-gnu)
- #107397 (Gracefully exit if --keep-stage flag is used on a clean source tree)
- #107401 (remove the usize field from CandidateSource::AliasBound)
- #107413 (make more pleasant to read)
- #107422 (Also erase substs for new infcx in pin move error)
- #107425 (Check for missing space between fat arrow and range pattern)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix def-use dominance check
A definition does not dominate a use in the same statement. For example
in MIR generated for compound assignment x += a (when overflow checks
are disabled).
Use stable metric for const eval limit instead of current terminator-based logic
This patch adds a `MirPass` that inserts a new MIR instruction `ConstEvalCounter` to any loops and function calls in the CFG. This instruction is used during Const Eval to count against the `const_eval_limit`, and emit the `StepLimitReached` error, replacing the current logic which uses Terminators only.
The new method of counting loops and function calls should be more stable across compiler versions (i.e., not cause crates that compiled successfully before, to no longer compile when changes to the MIR generation/optimization are made).
Also see: #103877
A definition does not dominate a use in the same statement. For example
in MIR generated for compound assignment x += a (when overflow checks
are disabled).
Append .dwp to the binary filename instead of replacing the existing extension.
gdb et al. expect to find the dwp file at `<binary>`.dwp, even if <binary> already has an extension (e.g. libfoo.so's dwp is expected to be at libfoo.so.dwp).
Rollup of 11 pull requests
Successful merges:
- #106407 (Improve proc macro attribute diagnostics)
- #106960 (Teach parser to understand fake anonymous enum syntax)
- #107085 (Custom MIR: Support binary and unary operations)
- #107086 (Print PID holding bootstrap build lock on Linux)
- #107175 (Fix escaping inference var ICE in `point_at_expr_source_of_inferred_type`)
- #107204 (suggest qualifying bare associated constants)
- #107248 (abi: add AddressSpace field to Primitive::Pointer )
- #107272 (Implement ObjectSafe and WF in the new solver)
- #107285 (Implement `Generator` and `Future` in the new solver)
- #107286 (ICE in new solver if we see an inference variable)
- #107313 (Add Style Team Triagebot config)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
InstCombine away intrinsic validity assertions
This optimization (currently) fires 246 times on the standard library. It seems to fire hardly at all on the big crates in the benchmark suite. Interesting.
This patch adds a `MirPass` that tracks the number of back-edges and
function calls in the CFG, adds a new MIR instruction to increment a
counter every time they are encountered during Const Eval, and emit a
warning if a configured limit is breached.
...and remove it from `PointeeInfo`, which isn't meant for this.
There are still various places (marked with FIXMEs) that assume all pointers
have the same size and alignment. Fixing this requires parsing non-default
address spaces in the data layout string, which will be done in a followup.
gdb et al. expect to find the dwp file at <binary>.dwp, even if <binary> already
has an extension (e.g. libfoo.so's dwp is expected to be at libfoo.so.dwp).
The optimization that removes artifacts when building libraries is correct
from the compiler's perspective but not from a debugger's perspective.
Unpacked split debuginfo is referred to by filename and debuggers need
the artifact that contains debuginfo to continue to exist at that path.
Ironically the test expects the correct behavior but it was not running.
Fix aarch64-unknown-linux-gnu_ilp32 target
This was broken because the synthetic object files produced by rustc were for 64-bit AArch64, which caused link failures when combined with 32-bit ILP32 object files.
This PR updates the object crate to 0.30.1 which adds support for generating ILP32 AArch64 object files.
riscv: Fix ELF header flags
The previous version added both `EF_RISCV_FLOAT_ABI_DOUBLE` and `EF_RISCV_RVC` if the "D" extension was enabled on riscv64 targets. riscv32 targets were not accounted for. This patch changes this so that:
- Only add `EF_RISCV_RVC` if the "C" extension is enabled
- Add `EF_RISCV_FLOAT_ABI_SINGLE` if the "F" extension is enabled and the "D" extension is not
- Add these ELF flags for riscv32 as well
Fixes#104284
r? rust-lang/risc-v
Linker drivers such as gcc, clang or lld often have a version postfix,
e.g clang-12. The previous logic would not account for this and would
fall back to guessing the linker flavor to be the default linker flavor
for the target, which causes linker errors when this is not the case.
By accounting for the possible version postfix and also considering
g++ and clang++, we considerably reduce the amount of times the
fallback guess has to be used.
To simplify matching check for a version postfix and match against the
linker stem without any version postfix.
In contrast to gcc, clang supports all architectures in one binary.
This means there are no variants like `aarch64-linux-gnu-clang` and
there is no need to check for `-clang` variants.
The previous version added both `EF_RISCV_FLOAT_ABI_DOUBLE` and
`EF_RISCV_RVC` if the "D" extension was enabled on riscv64 targets.
riscv32 targets were not accounted for. This patch changes this
so that:
- Only add `EF_RISCV_RVC` if the "C" extension is enabled
- Add `EF_RISCV_FLOAT_ABI_SINGLE` if the "F" extension is enabled
and the "D" extension is not
- Add these ELF flags for riscv32 as well
Allow codegen to unsize `dyn*` to `dyn`
`dyn* Trait` is just another type that implements `Trait`, so we should be able to unsize `&dyn* Trait` into `&dyn Trait` perfectly fine, same for `Box` and other unsizeable types.
Fixes#106488
This was broken because the synthetic object files produced by rustc
were for 64-bit AArch64, which caused link failures when combined with
32-bit ILP32 object files.
This PR updates the object crate to 0.30.1 which adds support for
generating ILP32 AArch64 object files.
Migrate `codegen_ssa` to diagnostics structs - [Part 3]
Completes migrating `codegen_ssa` module except 2 outstanding errors that depend on other crates:
1. [`rustc_middle::mir::interpret::InterpError`](b6097f2e1b/compiler/rustc_middle/src/mir/interpret/error.rs (L475)): I saw `rustc_middle` is unassigned, I am open to take this work.
2. `codegen_llvm`'s use of `fn span_invalid_monomorphization_error`, which I started to replace in the [last commit](9a31b3cdda) of this PR, but would like to know the team's preference on how we should keep replacing the other macros:
2.1. Update macros to expect a `Diagnostic`
2.2. Remove macros and expand the code on each use.
See [some examples of the different options in this experimental commit](64aee83e80)
_Part 2 - https://github.com/rust-lang/rust/pull/103792_
r? ``@davidtwco``
Cc ``@compiler-errors``
Small fixes for --crate-type staticlib
The first commit doesn't have an effect until we start translating error messages. The second commit fixes potential linker errors when combining `--crate-type staticlib` with another crate type and I think `-Cprefer-dynamic`.
On macOS, it's not yet clear which cases of clang/OS/target/SDK version impact
how to find ld/lld/rust-lld. The --target is not needed on our current targets with
a vanilla config, but may be in some cases. Specifying it all the time breaks the 10.7+
targets on x64 macOS.
We try to only specify it on macOS if the linker flavors are different,
for possible cases of cross-compilation with `-Zgcc-ld=lld` but the
expectation is that it should be passed manually when needed in these
situations.
Don't perform invalid checks in `codegen_attrs`
The attributes `#[track_caller]` and `#[cmse_nonsecure_entry]` are only valid on functions. When validating one of these attributes, codegen_attrs previously called `fn_sig`, [which can only be used on functions](https://github.com/rust-lang/rust/pull/105201), on the item the attribute was attached to, assuming that the item was a function without checking. This led to [ICEs in situations where the attribute was incorrectly used on non-functions](https://github.com/rust-lang/rust/issues/105594).
With this change, we skip calling `fn_sig` if the item the attribute is attached to must be a function but isn't, because `check_attr` will reject such cases without codegen_attrs's intervention.
As a side note, some of the attributes in codegen_attrs are only valid on functions, but that property isn't actually checked. I'm planning to fix that in a follow up PR since it's a behavior change that will need to be validated rather than an obvious bugfix. Thankfully, all the attributes like that I've found so far are unstable.
Fixes#105594.
r? `@cjgillot`
Remove wrapper functions for some unstable options
They are trivial and just forward to the option. Like most other options, we can just access it directly.
abort immediately on bad mem::zeroed/uninit
Now that we have non-unwinding panics, let's use them for these assertions. This re-establishes the property that `mem::uninitialized` and `mem::zeroed` will never unwind -- the earlier approach of causing panics here sometimes led to hard-to-debug segfaults when the surrounding code was not able to cope with the unexpected unwinding.
Cc `@bjorn3` I did not touch cranelift but I assume it needs a similar patch. However it has a `codegen_panic` abstraction that I did not want to touch since I didn't know how else it is used.
Rename `assert_uninit_valid` intrinsic
It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that.
This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if #100423 lands so removing it may be a bit over eager.
r? `@RalfJung`
Some attributes are only valid on function items. When checking these
attributes, codegen_attrs previously sometimes called `fn_sig` on the
item they were attached to without first ensuring that the item was a
function. This led to an ICE (#105594), since `fn_sig` can
only be called on functions.
After this change, we skip calling `fn_sig` if the item the attribute is
attached to must be a function but invalidly isn't, because `check_attr`
will reject such cases without codegen_attrs's intervention.
Combine `ty::Projection` and `ty::Opaque` into `ty::Alias`
Implements https://github.com/rust-lang/types-team/issues/79.
This PR consolidates `ty::Projection` and `ty::Opaque` into a single `ty::Alias`, with an `AliasKind` and `AliasTy` type (renamed from `ty::ProjectionTy`, which is the inner data of `ty::Projection`) defined as so:
```
enum AliasKind {
Projection,
Opaque,
}
struct AliasTy<'tcx> {
def_id: DefId,
substs: SubstsRef<'tcx>,
}
```
Since we don't have access to `TyCtxt` in type flags computation, and because repeatedly calling `DefKind` on the def-id is expensive, these two types are distinguished with `ty::AliasKind`, conveniently glob-imported into `ty::{Projection, Opaque}`. For example:
```diff
match ty.kind() {
- ty::Opaque(..) =>
+ ty::Alias(ty::Opaque, ..) => {}
_ => {}
}
```
This PR also consolidates match arms that treated `ty::Opaque` and `ty::Projection` identically.
r? `@ghost`
Use struct types during codegen in less places
This makes it easier to use cg_ssa from a backend like Cranelift that doesn't have any struct types at all. After this PR struct types are still used for function arguments and return values. Removing those usages is harder but should still be doable.
compiler: remove unnecessary imports and qualified paths
Some of these imports were necessary before Edition 2021, others were already in the prelude.
I hope it's fine that this PR is so spread-out across files :/
Fix invalid codegen during debuginfo lowering
In order for LLVM to correctly generate debuginfo for msvc, we sometimes need to spill arguments to the stack and perform some direct & indirect offsets into the value. Previously, this code always performed those actions, even when not required as LLVM would clean it up during optimization.
However, when MIR inlining is enabled, this can cause problems as the operations occur prior to the spilled value being initialized. To solve this, we first calculate the necessary offsets using just the type which is side-effect free and does not alter the LLVM IR. Then, if we are in a situation which requires us to generate the LLVM IR (and this situation only occurs for arguments, not local variables) then we perform the same calculation again, this time generating the appropriate LLVM IR as we go.
r? `@tmiasko` but feel free to reassign if you want 🙂Fixes#105386
Add LLVM KCFI support to the Rust compiler
This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
In order for LLVM to correctly generate debuginfo for msvc, we sometimes
need to spill arguments to the stack and perform some direct & indirect
offsets into the value. Previously, this code always performed those
actions, even when not required as LLVM would clean it up during
optimization.
However, when MIR inlining is enabled, this can cause problems as the
operations occur prior to the spilled value being initialized. To solve
this, we first calculate the necessary offsets using just the type which
is side-effect free and does not alter the LLVM IR. Then, if we are in a
situation which requires us to generate the LLVM IR (and this situation
only occurs for arguments, not local variables) then we perform the same
calculation again, this time generating the appropriate LLVM IR as we
go.
This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to
the Rust compiler. It initially provides forward-edge control flow
protection for operating systems kernels for Rust-compiled code only by
aggregating function pointers in groups identified by their return and
parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
rustc_codegen_ssa: Fix for codegen_get_discr
When doing the optimized implementation of getting the discriminant, the arithmetic needs to be done in the tag type so wrapping behavior works correctly.
Fixes#104519
rustc_codegen_ssa: write `.dwp` in a streaming fashion
When writing a `.dwp` file, rustc writes to a Vec first then to a BufWriter-wrapped file. It seems very likely that we can write in a streaming fashion to avoid double buffering in an intermediate Vec.
On my Linux machine, `.dwp` from the latest rust-lang/cargo is 113MiB. It may worth a stream writer, though I didn't do any benchmark 🙇🏾♂️.
deduplicate constant evaluation in cranelift backend
The cranelift backend had two matches on `ConstantKind`, which can be avoided, and used this `eval_for_mir` that nothing else uses... this makes things more consistent with the (better-tested) LLVM backend.
I noticed this because cranelift was the only user of `eval_for_mir`. However `try_eval_for_mir` still has one other user in `eval`... the odd thing is that the interpreter has its own `eval_mir_constant` which seems to duplicate the same functionality and does not use `try_eval_for_mir`. No idea what is happening here.
r? ``@bjorn3``
Cc ``@lcnr``
Improve generating Custom entry function
This commit is aimed at making compiler-generated entry functions (Basically just C `main` right now) more generic so other targets can do similar things for custom entry. This was initially implemented as part of https://github.com/rust-lang/rust/pull/100316.
Currently, this moves the entry function name and Call convention to the target spec.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
When doing the optimized implementation of getting the discriminant, the
arithmetic needs to be done in the tag type so wrapping behavior works
correctly.
Fixes#104519
Record `LocalDefId` in HIR nodes instead of a side table
This is part of an attempt to remove the `HirId -> LocalDefId` table from HIR.
This attempt is a prerequisite to creation of `LocalDefId` after HIR lowering (https://github.com/rust-lang/rust/pull/96840), by controlling how `def_id` information is accessed.
This first part adds the information to HIR nodes themselves instead of a table.
The second part is https://github.com/rust-lang/rust/pull/103902
The third part will be to make `hir::Visitor::visit_fn` take a `LocalDefId` as last parameter.
The fourth part will be to completely remove the side table.
cleanup and dedupe CTFE and Miri error reporting
It looks like most of the time, this error raised from const_prop_lint is just redundant -- it duplicates the error reported when evaluating the const-eval query. This lets us make `ConstEvalErr` private to the const_eval module which I think is a good step.
The Miri change mostly replaces a `match` by `if let`, and dedupes the "this error is impossible in Miri" checks.
r? ``@oli-obk``
Fixes https://github.com/rust-lang/rust/issues/75461
Issue error when -C link-self-contained option is used on unsupported platforms
The documentation was also updated to reflect this.
I'm assuming the supported platforms are the same as initially written in [RELEASES.md](https://github.com/rust-lang/rust/blob/master/RELEASES.md#compiler-17).
Fixes#103576
Fix some misleading target feature aliases
This is the first half of a fix for #100752. It looks like these aliases were added in #78361 and slipped under the radar, as these features are not AVX512. These features _do_ add AVX512 instructions when used _in combination_ with AVX512F, but without AVX512F, these features still provide 128-bit and 256-bit vector instructions. A user might be mislead into thinking these features imply AVX512F (which is true of the actual AVX512 features). This PR allows using the names as defined by LLVM, which matches Intel documentation.
A future PR should change the `std::arch` intrinsics to use these names, and finally remove these aliases from rustc.
r? ```@workingjubilee```
cc ```@Amanieu```
In `codegen_assert_terminator` we decide if a BB's successor is a
candidate for merging, which requires that it be the only successor, and
that it only have one predecessor. That result then gets passed down,
and if it reaches `funclet_br` with the appropriate BB characteristics,
then no `br` instruction is issued, a `MergingSucc::True` result is
passed back, and the merging proceeds in `codegen_block`.
The commit also adds `CachedLlbb`, a new type to help keep track of
each BB that has been merged into its predecessor.
For the next commit, `FunctionCx::codegen_*_terminator` need to take a
`&mut Bx` instead of consuming a `Bx`. This triggers a cascade of
similar changes across multiple functions. The resulting code is more
concise and replaces many `&mut bx` expressions with `bx`.
Wrap bundled static libraries into object files
Fixes#103044 (not sure, couldn't test locally)
Bundled static libraries should be wrapped into object files as it's done for metadata file.
r? `@petrochenkov`
Implement the `+whole-archive` modifier for `wasm-ld`
This implements the `Linker::{link_whole_staticlib,link_whole_rlib}` methods for the `WasmLd` linker used on wasm targets. Previously these methods were noops since I think historically `wasm-ld` did not have support for `--whole-archive` but nowadays it does, so the flags are passed through.
