mir_build: Rename `TestCase` to `TestableCase`
In the spirit of rust-lang/rust#149946, this is another renaming of something I've always found confusing.
When lowering match conditions, there is a subtle distinction between the kind of *test* being performed (on a scrutinee place), the possible outcomes of that test, and the different “cases” (corresponding to pattern nodes) that the test is distinguishing. Cases imply a particular preferred test, but once a test is chosen it can also interact with other cases as well.
I have often mixed up `TestKind` and `TestCase`, since the names are so similar, and they share several variant names. Therefore, this PR renames `TestCase` to `TestableCase`, to emphasise that these are the things selected by whatever test is being performed.
There should be no change to compiler behaviour.
Port `#[rustc_never_returns_null_ptr]` to attribute parser
Ports `#[rustc_never_returns_null_ptr]` to be parsed using the attribute parser
r? `@JonathanBrouwer`
Avoid unhelpful suggestion when crate name is invalid
Pointing out they can set the crate's name is non-actionable: their problem is they found out how and set it incorrectly. Remove extraneous information that can only confuse the matter.
Implement va_arg for Hexagon targets
Implements proper variadic argument handling for hexagon-unknown-linux-musl targets using a 3-pointer VaList structure compatible with LLVM's HexagonBuiltinVaList implementation.
* Handles register save area vs overflow area transition
* Provides proper 4-byte and 8-byte alignment for arguments
* Only activates for hexagon+musl targets via Arch::Hexagon & Env::Musl
Due to an erroneous overflow threshold, `expm1f` was incorrectly
returning `inf` for inputs in the range `[88.72169, 88.72283]`. This
additionally caused `sinhf` to return `NaN` for inputs in that range.
The bug was ported from the original in musl, which has since been fixed
in [1].
[1]: https://git.musl-libc.org/cgit/musl/commit/?id=964104f9f0e056cf58d9defa0b716d7756f040f6
Avoid using `Ord::clamp` in the `f16`-specific part of the generic
`scalbn`.
It turned out to be redundant anyway, as both callsites follow a pattern
like
```
if n < negative_val {
let foo = (n + positive_val).clamp(negative_val, positive_val);
}
```
and `n < negative_val < 0` implies `n + positive_val < positive_val`.
Fixes: rust-lang/compiler-builtins#1046
Pointing out they can set the crate's name is non-actionable:
their problem is they found out how and set it incorrectly.
Remove extraneous information that can only confuse the matter.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#150000 (Port `#[rustc_legacy_const_generics]` to use attribute parser )
- rust-lang/rust#150060 (autodiff: emit an error if we fail to find libEnzyme)
- rust-lang/rust#150070 (Partially revert rust-lang/rust#147888 and print warning if LLVM CMake dir is missing when building Enzyme)
- rust-lang/rust#150072 (Port #[no_link] to use attribute parser)
r? `@ghost`
`@rustbot` modify labels: rollup
Port #[no_link] to use attribute parser
Adds `#[no_link]` to the attribute parser, as well as adds tests making sure to FCW warn on `field`, `arm`, and `macrodef `
Partially revert #147888 and print warning if LLVM CMake dir is missing when building Enzyme
Partially reverts https://github.com/rust-lang/rust/pull/147888, Enzyme cannot be build with `download-ci-llvm = true`.
r? ``@ZuseZ4``
autodiff: emit an error if we fail to find libEnzyme
Tested manually by moving libEnzyme-21.so away. We should adjust the error msg. once we have the component up.
It's the first usage within rustc of this experimental feature, but afaik we're open to dogfooding those for test purpose, right?
r? ``@Kobzol``
Port `#[rustc_legacy_const_generics]` to use attribute parser
Small PR that ports the `#[rustc_legacy_const_generics]` to use the new attribute parser!
r? JonathanBrouwer
std: io: error: Add comment for UEFI unpacked repr use
The following commit adds the comment explaining the rational why UEFI uses unpacked representation on 64-bit platforms as opposed to bit-packed representation used in all other 64-bit platforms.
r? `@bjorn3`
Use annotate-snippet as default emitter on stable
This is implementation of https://github.com/rust-lang/rust/issues/149932
Now, after MCP was accepted, we can use annotate-snippet as default emitter for errors, that means that we not longer need of previous emitter, so this PR removed previous emitter and makes annotate-snippet new default one both on stable and nightly
(this PR does not remove a code of previous emitter it just removes a `Default` option of `HumanReadableErrorType` enum, and keeping only `HumanReadableErrorType::AnnotateSnippet` as it now uses by default)
dont create unnecessary `DefId`s under mgca
Fixesrust-lang/rust#149977Fixesrust-lang/rust#148838
Accidentally left this out of rust-lang/rust#149136 even though being able to do this was a large part of the point of the PR :3
First ICE was caused by the fact that we create a defid but never lower the nodeid associated with it to a hirid which later parts of the compiler can't handle.
See test for second ICE
r? oli-obk
custom `VaList` layout for Hexagon
I noticed while browsing LLVM source that we use an incorrect `VaList` definition for the musl hexagon target.
relevant links
- 0cdc1b6dd4/clang/include/clang/Basic/TargetInfo.h (L333)
- 0cdc1b6dd4/clang/lib/CodeGen/Targets/Hexagon.cpp (L407-L417)
cc target maintainer `@androm3da` can you confirm that this looks OK? In particular the `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute is used to simulate pointer decay (like if the struct were wrapped in a 1-element array in C). The clang comment suggests that the Tag is wrapped in such a single-element array, but I haven't actually been able to confirm it.
For stabilizing `c_variadic` (on the hexagon targets) we will also need a custom `va_arg` implementation to mirror the one in `clang` in [va_arg.rs](https://github.com/rust-lang/rust/blob/main/compiler/rustc_codegen_llvm/src/va_arg.rs). Would you be able to contribute one?
r? `@workingjubilee`
Tidying up tests/ui/issues 33 tests [4/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
`tests/ui/compile-flags` split it into `tests/ui/compile-flags/invalid/` and `tests/ui/compile-flags/run-pass/`
r? Kivooeo
The following commit adds the comment explaining the rational why UEFI
uses unpacked representation on 64-bit platforms as opposed to bit-packed
representation used in all other 64-bit platforms.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Fix span note for question mark expression
Fixesrust-lang/rust#144304
Seems it's better to fix the note instead of modifying the span to cover the whole expression.
r? `@estebank`
`rustc_scalable_vector(N)`
Supercedes rust-lang/rust#118917.
Initial experimental implementation of rust-lang/rfcs#3838. Introduces a `rustc_scalable_vector(N)` attribute that can be applied to types with a single `[$ty]` field (for `u{16,32,64}`, `i{16,32,64}`, `f{32,64}`, `bool`). `rustc_scalable_vector` types are lowered to scalable vectors in the codegen backend.
As with any unstable feature, there will necessarily be follow-ups as we experiment and find cases that we've not considered or still need some logic to handle, but this aims to be a decent baseline to start from.
See rust-lang/rust#145052 for request for a lang experiment.
The `fmt::Debug` impl for `TyAndLayout<'a, Ty>'` requires `fmt::Display`
on the `Ty` parameter. In `ArgAbi`, `TyAndLayout`'s Ty` is instantiated
with a parameter that implements `TyAbiInterface`. `TyAbiInterface`
only required `fmt::Debug` be implemented on `Self`, not `fmt::Display`,
which meant that it wasn't actually possible to debug print `ArgAbi`.
