| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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 fixes rust-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.
Closes rust-lang/rust#140293
|
|
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``
|
|
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.
|
|
Introduce CoerceShared lang item and trait, and basic Reborrow tests
Part of rust-lang/rust#145612: This introduces the `CoerceShared` trait which is the `Reborrow` equivalent of a `&mut T` -> `&T` coercion. The trait has a `Target` GAT which makes this (currently) unique in the `core/src/marker.rs`; I'm not sure if this can be considered problematic. Maybe this is not the way such things should be done at the marker trait level? Or maybe it is fine.
Improtantly, this PR introduces a battery of basic `Reborrow` and `CoerceShared` tests. These test the very basics of the feature; custom marker types intended to have exclusive semantics (`Custom<'a>(PhantomData<&'a mut ()>)`), custom exclusive reference wrappers, and standard library exclusive reference wrappers (`Pin<&mut T>` and `Option<&mut T>`). None of these of course work since the implementation for `Reborrow` and `CoerceShared` is entirely missing, but this is the first step towards making these work.
Future PRs will introduce more tests, such as "recursive" reborrowing (ie. reborrowing structs that contain multiple reborrowable fields) and checks around the lifetime semantics of reborrowing ie. that a reborrow produces a new type with the same lifetime as the original.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add an attribute to check the number of lanes in a SIMD vector after monomorphization
Allows std::simd to drop the `LaneCount<N>: SupportedLaneCount` trait and maintain good error messages.
Also, extends rust-lang/rust#145967 by including spans in layout errors for all ADTs.
r? ``@RalfJung``
cc ``@workingjubilee`` ``@programmerjake``
|
|
monomorphization
Unify zero-length and oversized SIMD errors
|
|
Add panic=immediate-abort
MCP: https://github.com/rust-lang/compiler-team/issues/909
This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts.
In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`.
The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large.
`-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing.
The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature.
To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it.
I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
|
|
|
|
|
|
|
|
Remove Rvalue::Len again.
Now that we have `RawPtrKind::FakeForPtrMetadata`, we can reimplement `Rvalue::Len` using `PtrMetadata(&raw const (fake) place)`.
r? ``@scottmcm``
|
|
initial implementation of the darwin_objc unstable feature
Tracking issue: https://github.com/rust-lang/rust/issues/145496
This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time.
r? ```@tmandry```
try-job: `*apple*`
try-job: `x86_64-gnu-nopt`
|
|
|
|
|
|
|
|
Some hygiene doc improvements
Improve some doc comments around SyntaxContext, outer_expn and friends.
Based on discussion at https://github.com/rust-lang/rust/pull/146100.
r? petrochenkov
|
|
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 fixes 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.
|
|
report duplicate symbols added by the driver
The panic message did not mention what symbols were duplicates, which made the panic hard to debug. This came up in [#t-compiler/help > Easiest way to find offending duplicate symbols](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Easiest.20way.20to.20find.20offending.20duplicate.20symbols/with/538295740).
This behavior was introduced in https://github.com/rust-lang/rust/pull/138682.
r? ```@fee1-dead```
|
|
Minor symbol comment fixes.
- The empty symbol is no longer a keyword.
- I don't think any of the special reserved identifiers are used for error recovery.
r? ```@petrochenkov```
|
|
r=jdonszelmann,ralfjung,traviscross
Implement `#[rustc_align_static(N)]` on `static`s
Tracking issue: https://github.com/rust-lang/rust/issues/146177
```rust
#![feature(static_align)]
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;
```
We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.
r? `@traviscross`
|
|
inclusive `Range`s: change `end` to `last`
Tracking issue: rust-lang/rust#125687
ACP: rust-lang/libs-team#511
|
|
We need a different attribute than `rustc_align` because unstable attributes are
tied to their feature (we can't have two unstable features use the same
unstable attribute). Otherwise this uses all of the same infrastructure
as `#[rustc_align]`.
|
|
|
|
|
|
- The empty symbol is no longer a keyword.
- I don't think any of the special reserved identifiers are used for
error recovery.
|
|
This reverts commit 5b43244ac59119870c9e0f6b642340ab88355b23 to fix
native build failures on LoongArch.
|
|
|
|
Implement Integer funnel shifts
Tracking issue: rust-lang/rust#145686
ACP: https://github.com/rust-lang/libs-team/issues/642
This implements funnel shifts on primitive integer types. Implements this for cg_llvm, with a fallback impl for everything else
Thanks `@folkertdev` for the fixes and tests
cc `@rust-lang/libs-api`
|
|
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.
|
|
Allow `inline(always)` with a target feature behind a unstable feature `target_feature_inline_always`.
Rather than adding the inline always attribute to the function definition, we add it to the callsite. We can then check that the target features match and that the call would be safe to inline. If the function isn't inlined due to a mismatch, we emit a warning informing the user that the function can't be inlined due to the target feature mismatch.
See tracking issue rust-lang/rust#145574
|
|
- Add a fallback implementation for the intrinsics
- Add LLVM backend support for funnel shifts
Co-Authored-By: folkertdev <folkert@folkertdev.nl>
|
|
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.
|
|
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
|
|
str: Stabilize `round_char_boundary` feature
Closes https://github.com/rust-lang/rust/issues/93743
FCP completed https://github.com/rust-lang/rust/issues/93743#issuecomment-3168382171
|
|
Add more to the `[workspace.dependencies]` section in the top-level `Cargo.toml`
Following on from rust-lang/rust#145740.
r? `@Kobzol`
|
|
Add new `doc(attribute = "...")` attribute
Fixes rust-lang/rust#141123.
The implementation and purpose of this new `#[doc(attribute = "...")]` attribute is very close to `#[doc(keyword = "...")]`. Which means that luckily for us, most of the code needed was already in place and `@Noratrieb` nicely wrote a first draft that helped me implement this new attribute very fast.
Now with all this said, there is one thing I didn't do yet: adding a `rustdoc-js-std` test. I added GUI tests with search results for attributes so should be fine but I still plan on adding one for it once documentation for builtin attributes will be written into the core/std libs.
You can test it [here](https://rustdoc.crud.net/imperio/doc-attribute-attribute/foo/index.html).
cc `@Noratrieb` `@Veykril`
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
|
|
|
|
rustc_codegen_ssa: More comprehensive RISC-V ELF flags
This change implements more conformant, more comprehensive RISC-V ELF flags handling when generating certain object files directly from rustc.
* Use `"zca"` instead of `"c"`
The "Zca" extension (a subset of "C") is the minimal configuration for compressed instructions to set `EF_RISCV_RVC` flag.
* Set TSO flag from `"ztso"`
The "Ztso" extension denotes that the program depends on the RVTSO (Total Store Ordering) memory consistency model, which is stronger than the standard RVWMO (Weak Memory Ordering) consistency model and on ELF targets, we need to set `EF_RISCV_TSO` flag.
|
