| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
r=rcvalle
Sanitizers target modificators
Depends on bool flag fix: https://github.com/rust-lang/rust/pull/138483.
Some sanitizers need to be target modifiers, and some do not. For now, we should mark all sanitizers as target modifiers except for these: AddressSanitizer, LeakSanitizer
For kCFI, the helper flag -Zsanitizer-cfi-normalize-integers should also be a target modifier.
Many test errors was with sanizer flags inconsistent with std deps. Tests are fixed with `-C unsafe-allow-abi-mismatch`.
|
|
|
|
modifiers with custom consistency check function
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Stabilize loongarch32 inline asm
r? ````````@Amanieu````````
|
|
If the baseline s390x cpu is changed to a newer variant, such as z13,
the vector feature may be enabled by default. When rust is packaged
on fedora 38 and newer, it is set to z13.
Explicitly disable vector support on the baseline test for consistent
results across s390x cpus.
|
|
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#140871 (Don't lint against named labels in `naked_asm!`)
- rust-lang/rust#141663 (rustdoc: add ways of collapsing all impl blocks)
- rust-lang/rust#143272 (Upgrade the `fortanix-sgx-abi` dependency)
- rust-lang/rust#143585 (`loop_match`: suggest extracting to a `const` item)
- rust-lang/rust#143698 (Fix unused_parens false positive)
- rust-lang/rust#143859 (Guarantee 8 bytes of alignment in Thread::into_raw)
- rust-lang/rust#144160 (tests: debuginfo: Work around or disable broken tests on powerpc)
- rust-lang/rust#144412 (Small cleanup: Use LocalKey<Cell> methods more)
- rust-lang/rust#144431 (Disable has_reliable_f128_math on musl targets)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Naked functions are allowed to define global labels, just like
`global_asm!`.
|
|
|
|
|
|
From `#[align]` -> `#[rustc_align]`. Attributes starting with `rustc`
are always perma-unstable and feature-gated by `feature(rustc_attrs)`.
See regression RUST-143834.
For the underlying problem where even introducing new feature-gated
unstable built-in attributes can break user code such as
```rs
macro_rules! align {
() => {
/* .. */
};
}
pub(crate) use align; // `use` here becomes ambiguous
```
refer to RUST-134963.
Since the `#[align]` attribute is still feature-gated by
`feature(fn_align)`, we can rename it as a mitigation. Note that
`#[rustc_align]` will obviously mean that current unstable user code
using `feature(fn_aling)` will need additionally `feature(rustc_attrs)`,
but this is a short-term mitigation to buy time, and is expected to be
changed to a better name with less collision potential.
See
<https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202025-07-17/near/529290371>
where mitigation options were considered.
|
|
fix `-Zsanitizer=kcfi` on `#[naked]` functions
fixes https://github.com/rust-lang/rust/issues/143266
With `-Zsanitizer=kcfi`, indirect calls happen via generated intermediate shim that forwards the call. The generated shim preserves the attributes of the original, including `#[unsafe(naked)]`. The shim is not a naked function though, and violates its invariants (like having a body that consists of a single `naked_asm!` call).
My fix here is to match on the `InstanceKind`, and only use `codegen_naked_asm` when the instance is not a `ReifyShim`. That does beg the question whether there are other `InstanceKind`s that could come up. As far as I can tell the answer is no: calling via `dyn` seems to work find, and `#[track_caller]` is disallowed in combination with `#[naked]`.
r? codegen
````@rustbot```` label +A-naked
cc ````@maurer```` ````@rcvalle````
|
|
There are many places that join path segments with `::` to produce a
string. A lot of these use `join("::")`. Many in rustdoc use
`join_with_double_colon`, and a few use `.joined("..")`. One in Clippy
uses `itertools::join`. A couple of them look for `kw::PathRoot` in the
first segment, which can be important.
This commit introduces `rustc_ast::join_path_{syms,ident}` to do the
joining for everyone. `rustc_ast` is as good a location for these as
any, being the earliest-running of the several crates with a `Path`
type. Two functions are needed because `Ident` printing is more complex
than simple `Symbol` printing.
The commit also removes `join_with_double_colon`, and
`estimate_item_path_byte_length` with it.
There are still a handful of places that join strings with "::" that are
unchanged. They are not that important: some of them are in tests, and
some of them first split a path around "::" and then rejoin with "::".
This fixes one test case where `{{root}}` shows up in an error message.
|
|
And more broadly only codegen `InstanceKind::Item` using the naked
function codegen code. Other instance kinds should follow the normal
path.
|
|
|
|
Some symbol and PathRoot cleanups
I'm looking into unifying how we join and print paths. Here are some preliminary cleanups.
r? ``@petrochenkov``
|
|
`{{root}}` is supposed to be an internal-only name but it shows up in
the output.
(I'm working towards a more general fix -- a universal "joiner" function
that can be used all over the place -- but I'm not there yet, so let's
fix this one in-place for now.)
|
|
Right now it's used for functions with `fn_align`, in the future it will
get more uses (statics, struct fields, etc.)
|
|
Update stdarch submodule
Updates the stdarch submodule.
## Merged PRs
- rust-lang/stdarch#1797
- rust-lang/stdarch#1758
- rust-lang/stdarch#1798
- rust-lang/stdarch#1811
- rust-lang/stdarch#1810
- rust-lang/stdarch#1807
- rust-lang/stdarch#1806
- rust-lang/stdarch#1812
- rust-lang/stdarch#1795
- rust-lang/stdarch#1796
- rust-lang/stdarch#1813
- rust-lang/stdarch#1816
- rust-lang/stdarch#1818
- rust-lang/stdarch#1820
- rust-lang/stdarch#1819
r? `@Amanieu`
`@rustbot` label T-libs-api
Closes rust-lang/rust#111137
|
|
r=traviscross,workingjubilee
Remove `i128` and `u128` from `improper_ctypes_definitions`
Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case:
* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at https://github.com/rust-lang/compiler-team/issues/683, implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at https://github.com/rust-lang/rust/pull/132422, https://github.com/rust-lang/rust/pull/132741, https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20 https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at https://github.com/rust-lang/rust/pull/134290.
At https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084, the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.
`repr(i128)` was added to this lint in https://github.com/rust-lang/rust/pull/138282, but is also removed here.
Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches.
Closes: https://github.com/rust-lang/rust/issues/134288
[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
|
|
|
|
|
|
|
|
Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:
* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
proposed at https://github.com/rust-lang/compiler-team/issues/683,
implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
Rust's data layouts adjusted at
https://github.com/rust-lang/rust/pull/132422,
https://github.com/rust-lang/rust/pull/132741,
https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20
https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
GCC and Clang at https://github.com/rust-lang/rust/pull/134290.
At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.
`repr(i128)` was added to this lint in [4], but is also removed here.
Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.
Closes: https://github.com/rust-lang/rust/issues/134288
Closes: https://github.com/rust-lang/rust/issues/128950
[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
[3]: https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084
[4]: https://github.com/rust-lang/rust/pull/138282
|
|
|
|
|
|
this is more in line with the x86 parse error tests. The cross-platform tests were more complete anyway
|
|
split `asm!` parsing and validation
This PR splits `asm!` parsing and validation into two separate steps.
The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros.
The validation then checks things like ordering of arguments or that options are not provided twice.
The motivation is https://github.com/rust-lang/rust/issues/140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`.
An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable https://github.com/rust-lang/style-team/issues/152).
r? ``@ghost`` (just want to look at CI for now)
cc ``@ytmimi`` we discussed asm formatting a little while ago in https://github.com/rust-lang/rustfmt/issues/6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before?
try-job: aarch64-apple
|
|
|
|
|
|
|
|
|
|
|
|
folkertdev:naked-function-rustc_std_internal_symbol, r=bjorn3
allow `#[rustc_std_internal_symbol]` in combination with `#[naked]`
The need for this came up in https://github.com/rust-lang/compiler-builtins/pull/897, but in general this seems useful and valid to allow.
Based on a quick scan, I don't think changes to the generated assembly are needed.
cc ``@bjorn3``
|
|
|
|
|
|
Move inline asm check to typeck, properly handle aliases
Pull `InlineAsmCtxt` down to `rustc_hir_typeck`, and instead of using things like `Ty::is_copy`, use the `InferCtxt`-aware methods. To fix https://github.com/rust-lang/trait-system-refactor-initiative/issues/189, we also add a `try_structurally_resolve_*` call to `expr_ty`.
r? lcnr
|
|
|
|
|
|
|
|
|
|
These emit prelude imports which means they are always edition dependent
|
|
upgrade to it
|
|
r=traviscross,compiler-errors
add `naked_functions_rustic_abi` feature gate
tracking issue: https://github.com/rust-lang/rust/issues/138997
Because the details of the rust abi are unstable, and a naked function must match its stated ABI, this feature gate keeps naked functions with a rustic abi ("Rust", "rust-cold", "rust-call" and "rust-intrinsic") unstable.
r? ````@traviscross````
|
|
|
|
|
