Fix our `llvm::Bool` typedef to be signed, to match `LLVMBool`
In the LLVM-C API, boolean values are passed as `typedef int LLVMBool`, but our Rust-side typedef was using `c_uint` instead.
Signed and unsigned integers have the same ABI on most platforms, but that isn't universally true, so we should prefer to be consistent with LLVM.
https://github.com/rust-lang/llvm-project/blob/1268e87/llvm/include/llvm-c/Types.h#L28
ABI checks: add support for loongarch
LoongArch psABI[^1] specifies that LSX vector types are passed via general-purpose registers, while LASX vector types are passed indirectly through the stack.
This patch addresses the following warnings:
```
warning: this function call uses a SIMD vector type that is not currently supported with the chosen ABI
--> .../library/core/src/../../stdarch/crates/core_arch/src/loongarch64/lsx/generated.rs:3695:5
|
3695 | __lsx_vreplgr2vr_b(a)
| ^^^^^^^^^^^^^^^^^^^^^ function called here
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558>
= note: `#[warn(abi_unsupported_vector_types)]` on by default
```
[^1]: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc
r? `@workingjubilee`
Add unpolished, experimental support for AFIDT (async fn in dyn trait)
This allows us to begin messing around `async fn` in `dyn Trait`. Calling an async fn from a trait object always returns a `dyn* Future<Output = ...>`.
To make it work, Implementations are currently required to return something that can be coerced to a `dyn* Future` (see the example in `tests/ui/async-await/dyn/works.rs`). If it's not the right size, then it'll raise an error at the coercion site (see the example in `tests/ui/async-await/dyn/wrong-size.rs`). Currently the only practical way of doing this is wrapping the body in `Box::pin(async move { .. })`.
This PR does not implement a helper type like a "`Boxing`"[^boxing] adapter, and I'll probably follow-up with another PR to improve the error message for the `PointerLike` trait (something that explains in just normal prose what is happening here, rather than a trait error).
[^boxing]: https://rust-lang.github.io/async-fundamentals-initiative/explainer/user_guide_future.html#the-boxing-adapter
This PR also does not implement new trait solver support for AFIDT; I'll need to think how best to integrate it into candidate assembly, and that's a bit of a matter of taste, but I don't think it will be difficult to do.
This could also be generalized:
* To work on functions that are `-> impl Future` (soon).
* To work on functions that are `-> impl Iterator` and other "dyn rpitit safe" traits. We still need to nail down exactly what is needed for this to be okay (not soon).
Tracking:
* https://github.com/rust-lang/rust/issues/133119
Revert "Stop git from merging generated files"
This reverts https://github.com/rust-lang/rust/pull/133851. "-merge" makes git not even do merges if they are entirely conflict-free, which is not the behavior we want. We sometimes have conflict-free merges in generated files and it's much better if git can handle them automatically.
r? `@oli-obk`
Cc `@jieyouxu` `@Urgau`
In the LLVM-C API, boolean values are passed as `typedef int LLVMBool`, but our
Rust-side typedef was using `c_uint` instead.
Signed and unsigned integers have the same ABI on most platforms, but that
isn't universally true, so we should prefer to be consistent with LLVM.
Rollup of 11 pull requests
Successful merges:
- #122003 (link libunwind dynamically and allow controlling it via `crt-static` on gnullvm targets)
- #133859 (Move some alloc tests to the alloctests crate)
- #134070 (Some asm! diagnostic adjustments and a papercut fix)
- #134144 (Properly consider APITs for never type fallback ascription fix)
- #134152 (Simplify `rustc_mir_dataflow::abs_domain`.)
- #134154 (suppress field expr with generics error message if it's a method)
- #134155 (Forbid `unsafe_op_in_unsafe_fn` for Hurd)
- #134173 (allow `symbol_intern_string_literal` lint in test modules)
- #134178 (Stabilize the Rust 2024 prelude)
- #134179 (Remove outdated consteval note from `<*mut T>::align_offset` docs.)
- #134187 (Remove `PErr`.)
r? `@ghost`
`@rustbot` modify labels: rollup
Stabilize the Rust 2024 prelude
This stabilizes the `core::prelude::rust_2024` and `std::prelude::rust_2024` modules. I missed these in the #133349 stabilization.
allow `symbol_intern_string_literal` lint in test modules
Since #133545, `x check compiler --stage 1` no longer works because compiler test modules trigger `symbol_intern_string_literal` lint errors. Bootstrap shouldn't control when to ignore or enable this lint in the compiler tree (using `Kind != Test` was ineffective for obvious reasons).
Also, conditionally adding this rustflag invalidates the build cache between `x test` and other commands.
This PR removes the `Kind` check from bootstrap and handles it directly in the compiler tree in a more natural way.
suppress field expr with generics error message if it's a method
Don't emit "field expressions may not have generic arguments" if it's a method call without `()`
r? estebank
Fixes#67680
Is this the best way to go? It's by far the simplest I could come up with.
Simplify `rustc_mir_dataflow::abs_domain`.
`rustc_mir_dataflow` has a typedef `AbstractElem` that is equal to `ProjectionElem<AbstractOperand, AbstractType>`. `AbstractOperand` and `AbstractType` are both unit types. There is also has a trait `Lift` to convert a `PlaceElem` to an `AbstractElem`.
But `rustc_mir_middle` already has a typedef `ProjectionKind` that is equal to `ProjectionElem<(), ()>`, which is equivalent to `AbstractElem`. So this commit reuses `ProjectionKind` in `rustc_mir_dataflow`, removes `AbstractElem`, and simplifies the `Lift` trait.
r? ``@pnkfelix``
Some asm! diagnostic adjustments and a papercut fix
Best reviewed commit by commit.
We forgot a `normalize` call in intrinsic checking, causing us to allow literal integers, but not named constants containing that literal. This can in theory affect stable code, but only if libstd contains a stable SIMD type that has an array length that is a named constant. I'd assume we'd have noticed by now due to asm! rejecting those outright.
The error message left me scratching my head for a bit, so I added some extra information to the diagnostic, too.
Move some alloc tests to the alloctests crate
Unit tests directly inside of standard library crates require a very fragile way of building that is hard to reproduce outside of bootstrap.
Pass end position of span through inline ASM cookie
Before this PR, only the start position of the span was passed though the inline ASM cookie to diagnostics. LLVM 19 has full support for 64-bit inline ASM cookies; this PR uses that to pass the end position of the span in the upper 32 bits, meaning inline ASM diagnostics now point at the entire line the error occurred on, not just the first character of it.
codegen `#[naked]` functions using global asm
tracking issue: https://github.com/rust-lang/rust/issues/90957Fixes#124375
This implements the approach suggested in the tracking issue: use the existing global assembly infrastructure to emit the body of `#[naked]` functions. The main advantage is that we now have full control over what gets generated, and are no longer dependent on LLVM not sneakily messing with our output (inlining, adding extra instructions, etc).
I discussed this approach with `@Amanieu` and while I think the general direction is correct, there is probably a bunch of stuff that needs to change or move around here. I'll leave some inline comments on things that I'm not sure about.
Combined with https://github.com/rust-lang/rust/pull/127853, if both accepted, I think that resolves all steps from the tracking issue.
r? `@Amanieu`
coverage: Rearrange the code for embedding per-function coverage metadata
This is a series of refactorings to the code that prepares and embeds per-function coverage metadata records (“covfun records”) in the `__llvm_covfun` linker section of the final binary. The `llvm-cov` tool reads this metadata from the binary when preparing a coverage report.
Beyond general cleanup, a big motivation behind these changes is to pave the way for re-landing an updated version of #133418.
---
There should be no change in compiler output, as demonstrated by the absence of (meaningful) changes to coverage tests.
The first patch is just moving code around, so I suggest looking at the other patches to see the actual changes.
---
try-job: x86_64-gnu
try-job: x86_64-msvc
try-job: aarch64-apple
De-duplicate and improve definition of core::ffi::c_char
Instead of having a list of unsigned char targets for each OS, follow the logic Clang uses and instead set the value based on architecture with a special case for Darwin and Windows operating systems. This makes it easier to support new operating systems targeting Arm/AArch64 without having to modify this config statement for each new OS. The new list does not quite match Clang since I noticed a few bugs in the Clang implementation (https://github.com/llvm/llvm-project/issues/115957).
Fixes https://github.com/rust-lang/rust/issues/129945
Closes https://github.com/rust-lang/rust/pull/131319
