| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Check that the gpu-kernel calling convention translates to
`amdgpu_kernel` when compiling for the amdgpu target.
|
|
Global variables are casted to the default address space works,
as the amdgpu target is now merged, a test can be added.
|
|
|
|
Adjust issue-118306.rs test after LLVM change
This updates tests/codegen-llvm/issues/issue-118306.rs to pass also after https://github.com/llvm/llvm-project/pull/155415
|
|
stabilize c-style varargs for sysv64, win64, efiapi, aapcs
This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to https://github.com/rust-lang/rust/pull/145954.
**Previous (combined) PR description:**
This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates.
The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](https://github.com/rust-lang/rust/issues/136946#issuecomment-2967847553) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR):
- "stdcall" for win32 targets **for non-variadic functions**
- "C" for everything else
This had been previously stabilized *without FCP* in https://github.com/rust-lang/rust/pull/116161, which got reverted in https://github.com/rust-lang/rust/pull/136897. There was also a "fun" race condition involved with the system ABI being [added](https://github.com/rust-lang/rust/pull/119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang/rust#116161.
There was a question raised [here](https://github.com/rust-lang/rust/pull/116161#issuecomment-1983829513) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me.
Fixes rust-lang/rust#100189
Cc `@rust-lang/lang`
# Stabilization report
> ## General design
> ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
AFAIK there is no RFC. The tracking issues are
- https://github.com/rust-lang/rust/issues/100189
- https://github.com/rust-lang/rust/issues/136946
> ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
The only controversial point is whether "system" ABI functions should support variadics.
- Pro: This allows crates like windows-rs to consistently use "system", see e.g. https://github.com/microsoft/windows-rs/issues/3626.
- Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](https://github.com/rust-lang/rust/issues/136946#issuecomment-2967847553). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those.
Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do
```rust
extern "system" {
// put all the things here
}
```
and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there).
(I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.)
> ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](https://github.com/rust-lang/rust/issues/44930).
> ## Has a Call for Testing period been conducted? If so, what feedback was received?
>
> Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results".
There was no call for testing.
A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics.
> ## Implementation quality
All rustc does here is forward the ABI to LLVM so there's lot a lot to say here...
> ### Summarize the major parts of the implementation and provide links into the code (or to PRs)
>
> An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>.
The check for allowed variadic ABIs is [here](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126).
The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/compiler/rustc_target/src/spec/abi_map.rs#L82-L85).
> ### Summarize existing test coverage of this feature
>
> Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing.
>
> Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time.
>
> - What does the test coverage landscape for this feature look like?
> - Tests for compiler errors when you use the feature wrongly or make mistakes?
> - Tests for the feature itself:
> - Limits of the feature (so failing compilation)
> - Exercises of edge cases of the feature
> - Tests that checks the feature works as expected (where applicable, `//@ run-pass`).
> - Are there any intentional gaps in test coverage?
>
> Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.).
Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64:
- https://github.com/rust-lang/rust/pull/144359
- https://github.com/rust-lang/rust/pull/144379
We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.)
The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`.
> ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
None that I am aware of.
> ### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
None that I am aware of.
> ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
`@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature.
> ### Which tools need to be adjusted to support this feature. Has this work been done?
>
> Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs.
Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here.
> ## Type system and execution rules
> ### What compilation-time checks are done that are needed to prevent undefined behavior?
>
> (Be sure to link to tests demonstrating that these tests are being done.)
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale?
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.)
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### What updates are needed to the reference/specification? (link to PRs when they exist)
- https://github.com/rust-lang/reference/pull/1936
> ## Common interactions
> ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
No.
> ### What other unstable features may be exposed by this feature?
None.
|
|
This updates tests/codegen-llvm/issues/issue-118306.rs to pass also
after https://github.com/llvm/llvm-project/pull/155415
|
|
|
|
pub async fn impl is monomorphized when func itself is monomorphized
Implentation coroutine (`func::{closure#0}`) is monomorphized, when func itself is monomorphized.
Currently, when `pub async fn foo(..)` is exported from lib and used in several dependent crates, only 'header' function is monomorphized in the defining crate. 'header' function, returning coroutine object, is monomorphized, but the coroutine's poll function (which actually implements all the logic for the function) is not. In such situation, `func::{closure#0}` will be monomorphized in every dependency.
This PR adds monomorphization for `func::{closure#0}` (coroutine poll function), when func itself is monomorphized.
Simple test with one lib async function and ten dependent crates (executable) that use the function, shows 5-7% compilation time improvement (single-threaded).
|
|
when func itself is monomorphized
|
|
Stabilize `array_repeat` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/126695) and stabilises `array::repeat`
|
|
r=scottmcm
Stabilize `strict_provenance_atomic_ptr` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/99108) and stabilises `AtomicPtr::{fetch_ptr_add, fetch_ptr_sub, fetch_byte_add, fetch_byte_sub, fetch_or, fetch_and, fetch_xor}`
---
EDIT: FCP completed at https://github.com/rust-lang/rust/issues/99108#issuecomment-3168260347
|
|
While provenance cannot be captured through these arguments, the
address / object identity can.
|
|
Add codegen-llvm regression tests
Most of these regressions deal with elimination of panics and bounds checks that were fixed upstream by LLVM.
closes https://github.com/rust-lang/rust/issues/141497
closes https://github.com/rust-lang/rust/issues/131162
closes https://github.com/rust-lang/rust/issues/129583
closes https://github.com/rust-lang/rust/issues/110971
closes https://github.com/rust-lang/rust/issues/91109
closes https://github.com/rust-lang/rust/issues/80075
closes https://github.com/rust-lang/rust/issues/74917
closes https://github.com/rust-lang/rust/issues/71997
closes https://github.com/rust-lang/rust/issues/71257
closes https://github.com/rust-lang/rust/issues/59352
|
|
update some s390x codegen tests
By using `minicore`, `&raw` and removing use of `link_llvm_intrinsics`
|
|
Consolidate panicking functions in `slice/index.rs`
Consolidate all the panicking functions in `slice/index.rs` to use a single `slice_index_fail` function, similar to how it is done in `str/traits.rs`.
Split off from https://github.com/rust-lang/rust/pull/145024
|
|
Consolidate all the panicking functions in `slice/index.rs` to use a single
`slice_index_fail` function, similar to how it is done in `str/traits.rs`.
|
|
|
|
modifiers with custom consistency check function
|
|
Enforce correct number of arguments for `"x86-interrupt"` functions
Tracking issue: rust-lang/rust#40180
Partially fixes rust-lang/rust#132835
`````@rustbot````` label: +F-abi_x86_interrupt +A-LLVM +O-x86_64 +O-x86_32 +A-ABI
|
|
Most of these regressions concern elimination of panics and bounds
checks that were fixed upstream by LLVM.
|
|
Tell LLVM about read-only captures
`&Freeze` parameters are not only `readonly` within the function, but any captures of the pointer can also only be used for reads. This can now be encoded using the `captures(address, read_provenance)` attribute.
|
|
Pass `alloc-variant-zeroed` to LLVM
Makes use of https://github.com/llvm/llvm-project/pull/138299 (once we pull in a version of LLVM with this attribute). ~~Unfortunately also requires https://github.com/llvm/llvm-project/pull/149336 to work.~~
Closes rust-lang/rust#104847
|
|
`&Freeze` parameters are not only `readonly` within the function,
but any captures of the pointer can also only be used for reads.
This can now be encoded using the `captures(address, read_provenance)`
attribute.
|
|
|
|
|
|
By using `minicore`, `&raw` and removing use of `link_llvm_intrinsics`
|
|
|
|
Add `-Zindirect-branch-cs-prefix`
Cc: ``@azhogin`` ``@Darksonn``
This goes on top of https://github.com/rust-lang/rust/pull/135927, i.e. please skip the first commit here. Please feel free to inherit it there.
In fact, I am not sure if there is any use case for the flag without `-Zretpoline*`. GCC and Clang allow it, though.
There is a `FIXME` for two `ignore`s in the test that I took from another test I did in the past -- they may be needed or not here since I didn't run the full CI. Either way, it is not critical.
Tracking issue: https://github.com/rust-lang/rust/issues/116852.
MCP: https://github.com/rust-lang/compiler-team/issues/868.
|
|
Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases
This PR resolves several test failures encountered when running `./x test` on the RISC-V architecture. These failures were caused by platform-specific behavior, ABI differences, or codegen inconsistencies unique to RISC-V.
The following test cases have been fixed to ensure compatibility with RISC-V:
* `codegen-llvm/enum/enum-match.rs`
* `codegen-llvm/enum/enum-transparent-extract.rs`
* `codegen-llvm/repeat-operand-zero-len.rs`
* `codegen-llvm/enum/enum-aggregate.rs`
* `codegen-llvm/uninhabited-transparent-return-abi.rs`
In addition, this PR adjusts `tests/codegen-llvm/transmute-scalar.rs` to explicitly specify the target architecture:
```rust
//@ compile-flags: --target=x86_64-unknown-linux-gnu
//@ needs-llvm-components: x86
```
As suggested by ```@nikic,``` this test is not target-specific and already uses `minicore`, implying it is meant to run against a stable triple regardless of the host architecture. Explicitly setting the target ensures consistent codegen behavior, particularly when testing on non-x86 platforms such as riscv64.
All changes have been tested locally on a RISC-V target and now pass as expected.
### Notes:
* These fixes are scoped specifically to enable full test suite compliance for RISC-V.
* No changes impact other architectures.
* The change to `transmute-scalar.rs` aligns with the intent of [[#143915](https://github.com/rust-lang/rust/pull/143915)](https://github.com/rust-lang/rust/pull/143915) and prevents architecture-dependent discrepancies during CI or local testing.
|
|
Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`
This came up during the sanitizer stabilization (rust-lang/rust#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)).
The new attribute also works on modules, traits and impl items and thus enables usage as the following:
```rust
#[sanitize(address = "off")]
mod foo {
fn unsanitized(..) {}
#[sanitize(address = "on")]
fn sanitized(..) {}
}
trait MyTrait {
#[sanitize(address = "off")]
fn unsanitized_default(..) {}
}
#[sanitize(thread = "off")]
impl MyTrait for () {
...
}
```
r? ```@rcvalle```
|
|
Resolve several ./x test failures on RISC-V caused by ABI and codegen
differences. Update multiple codegen-llvm tests for compatibility, and
explicitly set the target for transmute-scalar.rs to x86_64 to ensure
consistent behavior across hosts.
|
|
This removes the #[no_sanitize] attribute, which was behind an unstable
feature named no_sanitize. Instead, we introduce the sanitize attribute
which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off).
This also makes sanitize(kernel_address = ..) attribute work with
-Zsanitize=address
To do it the same as how clang disables address sanitizer, we now
disable ASAN on sanitize(kernel_address = "off") and KASAN on
sanitize(address = "off").
The same was added to clang in https://reviews.llvm.org/D44981.
|
|
This change implements the #[sanitize(..)] attribute, which opts to
replace the currently unstable #[no_sanitize]. Essentially the new
attribute works similar as #[no_sanitize], just with more flexible
options regarding where it is applied. E.g. it is possible to turn
a certain sanitizer either on or off:
`#[sanitize(address = "on|off")]`
This attribute now also applies to more places, e.g. it is possible
to turn off a sanitizer for an entire module or impl block:
```rust
\#[sanitize(address = "off")]
mod foo {
fn unsanitized(..) {}
#[sanitize(address = "on")]
fn sanitized(..) {}
}
\#[sanitize(thread = "off")]
impl MyTrait for () {
...
}
```
This attribute is enabled behind the unstable `sanitize` feature.
|
|
Add codegen test for issue 122734
Closes rust-lang/rust#122734
|
|
This is intended to be used for Linux kernel RETPOLINE builds.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
|
|
|
|
llvm: Accept new LLVM lifetime format
In llvm/llvm-project#150248 LLVM removed the size parameter from the lifetime format. Tolerate not having that size parameter.
|
|
|
|
|
|
Set dead_on_return attribute for indirect arguments
Set the dead_on_return attribute (added in LLVM 21) for arguments that are passed indirectly, but not byval.
This indicates that the value of the argument on return does not matter, enabling additional dead store elimination.
From LangRef:
> This attribute indicates that the memory pointed to by the argument is dead upon function return, both upon normal return and if the calls unwinds, meaning that the caller will not depend on its contents. Stores that would be observable either on the return path or on the unwind path may be elided.
>
> Specifically, the behavior is as-if any memory written through the pointer during the execution of the function is overwritten with a poison value upon function return. The caller may access the memory, but any load not preceded by a store will return poison.
>
> This attribute does not imply aliasing properties. For pointer arguments that do not alias other memory locations, noalias attribute may be used in conjunction. Conversely, this attribute always implies dead_on_unwind.
>
> This attribute cannot be applied to return values.
This fixes parts of https://github.com/rust-lang/rust/issues/96497.
|
|
LLVM removed the size parameter from the lifetime format.
Tolerate not having that size parameter.
|
|
Set the dead_on_return attribute (added in LLVM 21) for arguments
that are passed indirectly, but not byval.
This indicates that the value of the argument on return does not
matter, enabling additional dead store elimination.
|
|
Add regression test for `saturating_sub` bounds check issue
Add codegen test for issue where `valid_index.saturating_sub(X)` produced an extra bounds check.
This was fixed by the LLVM upgrade.
Closes rust-lang/rust#139759
|
|
|
|
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
|
|
r=petrochenkov
Prevent name collisions with internal implementation details
The implementation of the linkage attribute inside extern blocks defines symbols starting with _rust_extern_with_linkage_. If someone tries to also define this symbol you will get a symbol conflict or even an ICE. By adding an unpredictable component to the symbol name, this becomes less of an issue.
Spawned from the discussion at [#t-compiler > About static variables `_rust_extern_with_linkage_*`](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/About.20static.20variables.20.60_rust_extern_with_linkage_*.60) cc `@ywxt`
Fixes https://github.com/rust-lang/rust/issues/144940
|
|
Add codegen test for issue where `valid_index.saturating_sub(X)` produced an
extra bounds check.
This was fixed by the LLVM upgrade.
|
|
The implementation of the linkage attribute inside extern blocks defines
symbols starting with _rust_extern_with_linkage_. If someone tries to
also define this symbol you will get a symbol conflict or even an ICE.
By adding an unpredictable component to the symbol name, this becomes
less of an issue.
|
