| Age | Commit message (Collapse) | Author | Lines |
|---|
|
feature: fix typo in attribute description
The force inlining attribute isn't is never used with `#![..]` attribute syntax, only `#[..]` syntax.
|
|
remove `simd_fpow` and `simd_fpowi`
Discussed in https://github.com/rust-lang/rust/issues/137555
These functions are not exposed from `std::intrinsics::simd`, and not used anywhere outside of the compiler. They also don't lower to particularly good code at least on the major ISAs (I checked x86_64, aarch64, s390x, powerpc), where the vector is just spilled to the stack and scalar functions are used for the actual logic.
r? `@RalfJung`
|
|
Fix invalid suggestion from type error for derive macro
Fixes #136343
r? `@estebank`
I didn't use `from_expansion` to avoid it because of testcase
`tests/ui/typeck/issue-110017-format-into-help-deletes-macro.rs`:
https://github.com/chenyukang/rust/blob/11959a8b6e75d2c55500a703070a248342d29549/tests/ui/typeck/issue-110017-format-into-help-deletes-macro.rs#L34-L37
This type error could come up with a proper fix.
|
|
Improve behavior of `IF_LET_RESCOPE` around temporaries and place expressions
Heavily reworks the `IF_LET_RESCOPE` to be more sensitive around 1. temporaries that get consumed/terminated and therefore should not trigger the lint, and 2. borrows of place expressions, which are not temporary values.
Fixes #137411
|
|
Make `#[used]` work when linking with `ld64`
To make `#[used]` work in static libraries, we use the `symbols.o` trick introduced in https://github.com/rust-lang/rust/pull/95604.
However, the linker shipped with Xcode, ld64, works a bit differently from other linkers; in particular, [it completely ignores undefined symbols by themselves](https://github.com/apple-oss-distributions/ld64/blob/ld64-954.16/src/ld/parsers/macho_relocatable_file.cpp#L2455-L2468), and only consider them if they have relocations (something something atoms something fixups, I don't know the details).
So to make the `symbols.o` file work on ld64, we need to actually insert a relocation. That's kinda cumbersome to do though, since the relocation must be valid, and hence must point to a valid piece of machine code, and is hence very architecture-specific.
Fixes https://github.com/rust-lang/rust/issues/133491, see that for investigation.
---
Another option would be to pass `-u _foo` to the final linker invocation. This has the problem that `-u` causes the linker to not be able to dead-strip the symbol, which is undesirable. (If we did this, we would possibly also want to do it by putting the arguments in a file by itself, and passing that file via ``@`,` e.g. ``@undefined_symbols.txt`,` similar to https://github.com/rust-lang/rust/issues/52699, though that [is only supported since Xcode 12](https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes#Linking), and I'm not sure we wanna bump that).
Various other options that are probably all undesirable as they affect link time performance:
- Pass `-all_load` to the linker.
- Pass `-ObjC` to the linker (the Objective-C support in the linker has different code paths that load more of the binary), and instrument the binaries that contain `#[used]` symbols.
- Pass `-force_load` to libraries that contain `#[used]` symbols.
Failed attempt: Embed `-u _foo` in the object file with `LC_LINKER_OPTION`, akin to https://github.com/rust-lang/rust/issues/121293. Doesn't work, both because `ld64` doesn't read that from archive members unless it already has a reason to load the member (which is what this PR is trying to make it do), and because `ld64` only support the `-l`, `-needed-l`, `-framework` and `-needed_framework` flags in there.
---
TODO:
- [x] Support all Apple architectures.
- [x] Ensure that this works regardless of the actual type of the symbol.
- [x] Write up more docs.
- [x] Wire up a few proper tests.
`@rustbot` label O-apple
|
|
|
|
for unsized types
|
|
Rollup of 11 pull requests
Successful merges:
- #136522 (Remove `feature(dyn_compatible_for_dispatch)` from the compiler)
- #137289 (Consolidate and improve error messaging for `CoerceUnsized` and `DispatchFromDyn`)
- #137321 (Correct doc about `temp_dir()` behavior on Android)
- #137417 (rustc_target: Add more RISC-V atomic-related features)
- #137489 (remove `#[rustc_intrinsic_must_be_overridde]`)
- #137530 (DWARF mixed versions with LTO on MIPS)
- #137543 (std: Fix another new symlink test on Windows)
- #137548 (Pass correct `TypingEnv` to `InlineAsmCtxt`)
- #137550 (Don't immediately panic if dropck fails without returning errors)
- #137552 (Update books)
- #137556 (rename simd_shuffle_generic → simd_shuffle_const_generic)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rename simd_shuffle_generic → simd_shuffle_const_generic
I've been confused by this name one time too often. ;)
r? `@oli-obk`
|
|
matthewjasper:panic-later-for-missing-dropck-error, r=compiler-errors
Don't immediately panic if dropck fails without returning errors
This span_bug was a little too optimistic. I've decided that matching on the ErrorGuaranteed is a little more sensible than a delay bug that will always be ignored.
closes #137329
r? `@compiler-errors`
|
|
Pass correct `TypingEnv` to `InlineAsmCtxt`
Fixes #137512
r? oli-obk
|
|
RalfJung:no-more-rustc_intrinsic_must_be_overridden, r=oli-obk
remove `#[rustc_intrinsic_must_be_overridde]`
In https://github.com/rust-lang/rust/pull/135031, we gained support for just leaving away the body. Now that the bootstrap compiler got bumped, stop using the old style and remove support for it.
r? `@oli-obk`
There are a few more mentions of this attribute in RA code that I didn't touch; Cc `@rust-lang/rust-analyzer`
|
|
rustc_target: Add more RISC-V atomic-related features
This is a continuation of https://github.com/rust-lang/rust/pull/130877 and adds a few target features, including `zacas`, which was experimental in LLVM 19 and marked non-experimental in LLVM 20.
This adds the following target features to unstable riscv_target_feature:
- `za64rs` (Za64rs Extension 1.0): Reservation Set Size of at Most 64 Bytes
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0-rc2/llvm/lib/Target/RISCV/RISCVFeatures.td#L227-L228), [available since LLVM 18](https://github.com/llvm/llvm-project/commit/8649328060b4e748502d1d859f9c9c1bd3c2bccc))
- `za128rs` (Za128rs Extension 1.0): Reservation Set Size of at Most 128 Bytes
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0-rc2/llvm/lib/Target/RISCV/RISCVFeatures.td#L230-L231), [available since LLVM 18](https://github.com/llvm/llvm-project/commit/8649328060b4e748502d1d859f9c9c1bd3c2bccc))
- IIUC, `za*rs` can be referenced when implementing helpers to reduce contention in synchronization primitives, like [`crossbeam_utils::CachePadded`](https://docs.rs/crossbeam-utils/latest/crossbeam_utils/struct.CachePadded.html). (relevant discussion: https://github.com/riscv/riscv-profiles/issues/79)
- `zacas` (Zacas Extension 1.0): Atomic Compare-And-Swap Instructions (`amocas.{w,d,q}{,.aq,.rl,.aqrl}` and `amocas.{b,h}{,.aq,.rl,.aqrl}` when `zabha` is also enabled)
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0-rc2/llvm/lib/Target/RISCV/RISCVFeatures.td#L240-L243), [available as non-experimental since LLVM 20](https://github.com/llvm/llvm-project/commit/614aeda93b2225c6eb42b00ba189ba7ca2585c60))
- This implies `zaamo`.
- This is used to optimize CAS in existing atomics and/or implement 64-bit/128-bit atomics on riscv32/riscv64 (e.g., https://github.com/taiki-e/portable-atomic/pull/173).
- Note that [LLVM does not automatically use this instruction for 64-bit/128-bit atomics on riscv32/riscv64 even if this feature is enabled, because doing it changes the ABI](https://github.com/llvm/llvm-project/blob/876174ffd7533dc220f94721173bb767b659fa7f/llvm/docs/RISCVUsage.rst#riscv-zacas-note). (If the ability to do that is provided by LLVM in the future, it should probably be controlled by another ABI feature similar to `forced-atomics`.)
- `zama16b` (Zama16b Extension 1.0): Atomic 16-byte misaligned loads, stores and AMOs
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0-rc2/llvm/lib/Target/RISCV/RISCVFeatures.td#L255-L256), [available since LLVM 19](https://github.com/llvm/llvm-project/commit/b090569685699abe4a8031ad442a0f81e373146b))
- IIUC, unlike AArch64 FEAT_LSE2 which also makes 16-byte aligned ldp ({i,u}128 load) atomic, this extension only affects instructions that already considered atomic if they were naturally aligned. i.e., fld (f64 load) on riscv32 would not be atomic with or without this extension ([relevant QEMU code](https://github.com/qemu/qemu/blob/b69801dd6b1eb4d107f7c2f643adf0a4e3ec9124/target/riscv/insn_trans/trans_rvd.c.inc#L50-L62)).
- `zawrs` (Zawrs Extension 1.0): Wait on Reservation Set (`wrs.nto` and `wrs.sto`)
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0-rc2/llvm/lib/Target/RISCV/RISCVFeatures.td#L258), [available as non-experimental since LLVM 17](https://github.com/llvm/llvm-project/commit/d41a73aa94cb8945dcd0f2906992c2fcea6ed001))
- This is used to optimize synchronization primitives (e.g., Linux uses this for spinlocks (https://github.com/torvalds/linux/commit/b8ddb0df30f9f6e70422f1e705b7416da115bd24)).
Btw, the question of whether `zaamo` is implied by `zabha` or not, which was discussed in https://github.com/rust-lang/rust/pull/130877, has been resolved in LLVM 20, since LLVM now treats `zaamo` as implied by `zabha`/`zacas` (https://github.com/llvm/llvm-project/pull/115694), just like GCC and rustc.
r? `@Amanieu`
`@rustbot` label +O-riscv +A-target-feature
|
|
Consolidate and improve error messaging for `CoerceUnsized` and `DispatchFromDyn`
Firstly, this PR consolidates and reworks the error diagnostics for `CoercePointee` and `DispatchFromDyn`. There was a ton of duplication for no reason -- this reworks both the errors and also the error codes, since they can be shared between both traits since they report the same thing.
Secondly, when encountering a struct with multiple fields that must be coerced, point out the field spans, rather than mentioning the fields by name. This makes the error message clearer, but also means that we don't mention the `__S` dummy parameter for `derive(CoercePointee)`.
Thirdly, emit a custom error message when we encounter a trait error that comes from the recursive field `CoerceUnsized`/`DispatchFromDyn` trait check. **Note:** This is the only one I'm not too satisfied with -- I think it could use some more refinement, but ideally it explains that the field must be an unsize-able pointer... Feedback welcome.
Finally, don't emit `DispatchFromDyn` validity errors if we detect `CoerceUnsized` validity errors from an impl of the same ADT.
This is best reviewed per commit.
r? `@oli-obk` perhaps?
cc `@dingxiangfei2009` -- sorry for making my own attempt at this PR, but I wanted to see if I could implement a fix for #136796 in a less complicated way, since communicating over github review comments can be a bit slow. I'll leave comments inline to explain my thinking about the diagnostics changes.
|
|
|
|
|
|
|
|
|
|
these were ignored because of #45351, but that issue has long been fixed. Let's see if these pass, or if there is some issue lurking still
|
|
|
|
|
|
|
|
Type lowering can give non-fatal errors that dropck then uses to suppress its own errors. Assume this is the cases when we can't find the error in borrowck.
|
|
|
|
macro
|
|
|
|
|
|
|
|
note: compiler compiles but librustdoc and clippy don't
|
|
Like trait predicates, the self type ought to be skipped here.
|
|
Added to demonstrate change in output in following commit. Many more
interesting tests change with different output, missing errors, new
errors, etc related to this but they all depend on feature flags and
are much more complex than this.
|
|
minicore makes it much easier to add new language items to all of the
existing `no_core` tests.
|
|
In the standard library, the `Extend` impl for `Iterator` (specialised
with `TrustedLen`) has a parameter which is constrained by a projection
predicate. This projection predicate provides a value for an inference
variable but host effect evaluation wasn't resolving variables first.
Adding the extra resolve can the number of errors in some tests when they
gain host effect predicates, but this is not unexpected as calls to
`resolve_vars_if_possible` can cause more error tainting to happen.
Co-authored-by: Boxy <rust@boxyuwu.dev>
|
|
The force inlining attribute isn't is never used with `#![..]` attribute
syntax, only `#[..]` syntax.
|
|
|
|
|
|
rename sub_ptr to offset_from_unsigned
i also made `byte_sub_ptr` `byte_offset_from_unsigned`
fixes #137121
tracking issue #95892
|
|
intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic
LLVM has three intrinsics here that all do the same thing (when used in the default FP environment). There's no reason Rust needs to copy that historically-grown mess -- let's just have one intrinsic and leave it up to the LLVM backend to decide how to lower that.
Suggested by `@hanna-kruppe` in https://github.com/rust-lang/rust/issues/136459; Cc `@tgross35`
try-job: test-various
|
|
|
|
vectorcall ABI: require SSE2
According to the official docs at https://learn.microsoft.com/en-us/cpp/cpp/vectorcall, SSE2 is required for this ABI. Add a check that enforces this.
I put this together with the other checks ensuring the target features required for a function are present... however, since the ABI is known pre-monomorphization, it would be possible to do this check earlier, which would have the advantage of checking even in `cargo check`. It would have the disadvantage of spreading this code in yet more places.
The first commit just does a little refactoring of the mono-time ABI check to make it easier to add the new check.
Cc `@workingjubilee`
try-job: dist-i586-gnu-i586-i686-musl
|
|
Fix missing self subst when rendering `impl Fn*<T>` with no output type
r? `@fmease` or reassign
Fixes #133597
cc #137456
|
|
Fix "missing match arm body" suggestion involving `!`
Include the match arm guard in the gated span, so that the suggestion to add a body is correct instead of inserting the body before the guard.
Make the suggestion verbose.
```
error: `match` arm with no body
--> $DIR/feature-gate-never_patterns.rs:43:9
|
LL | Some(_) if false,
| ^^^^^^^^^^^^^^^^
|
help: add a body after the pattern
|
LL | Some(_) if false => { todo!() },
| ++++++++++++++
```
r? `@compiler-errors`
|
|
Improve a bit HIR pretty printer
This PR improve (a bit) the HIR pretty printer.
It does so by:
- Not printing elided lifetimes (those are not expressible in surface Rust anyway)
- And by rendering implicit self with the shorthand syntax
I also tried fixing some indentation and other things but gave up for now.
Best reviewed commit by commit.
|
|
|
|
|
|
|
|
Remove invalid suggestion of into_iter for extern macro
Fixes #137345
#109082 is closed due to performance issue, do we have any other solution for this kind of issue?
|
|
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (https://github.com/rust-lang/rust/issues/137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to https://github.com/rust-lang/rust/pull/130443#issuecomment-2445678945, which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes #111709
Fixes #96304
Fixes #137179
|
|
stabilize `(const_)ptr_sub_ptr`
Tracking issue: #95892
Closes #95892
FCP Completed: https://github.com/rust-lang/rust/issues/95892#issuecomment-2561139730
r? ````@Noratrieb````
|
|
Inject `compiler_builtins` during postprocessing and ensure it is made private
Follow up of https://github.com/rust-lang/rust/pull/135278
Do the following:
* Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST
* Do not make dependencies of `std` private by default (this was added in #135278)
* Make sure sysroot crates correctly mark their dependencies private/public
* Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
* Do the `compiler_builtins` update that has been blocked on this
There is more detail in the commit messages. This includes the changes I was working on in https://github.com/rust-lang/rust/pull/136226.
try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2
|
