Remove `avx512dq` and `avx512vl` implication for `avx512fp16`
According to Intel, `avx512fp16` requires only `avx512bw`, but LLVM also enables `avx512vl` and `avx512dq` when `avx512fp16` is active. This is relic code, and will be fixed in LLVM soon. We should remove this from Rust too asap, especially before the stabilization of AVX512
Related:
- llvm/llvm-project#136209
- #138940
- rust-lang/stdarch#1781
- #111137
``@rustbot`` label O-x86_64 O-x86_32 A-SIMD A-target-feature T-compiler -T-libs
r? ``@Amanieu``
**Update: the LLVM fix has been merged**
cc ``@rust-lang/wg-llvm`` will it be possible to update the rustc llvm version to something after llvm/llvm-project#137450
rustc_target: RISC-V `Zfinx` is incompatible with `{ILP32,LP64}[FD]` ABIs
Because RISC-V Calling Conventions note that:
> This means code targeting the `Zfinx` extension always uses the ILP32, ILP32E or LP64 integer calling-convention only ABIs as there is no dedicated hardware floating-point register file.
`{ILP32,LP64}[FD]` ABIs with hardware floating-point calling conventions are incompatible with the `Zfinx` extension.
This commit adds `"zfinx"` to the incompatible feature list to those ABIs and tests whether trying to add `"zdinx"` (that is analogous to `"zfinx"` but in double-precision) on a LP64D ABI configuration results in an error (it also tests extension implication; `Zdinx` requires `Zfinx` extension).
Links: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/v1.0/riscv-cc.adoc#named-abis>
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
handle paren in macro expand for let-init-else expr
Fixes#131655
This PR modifies the codegen logic of the macro expansion within `let-init-else` expression:
- Before: The expression `let xxx = (mac! {}) else {}` expands to `let xxx = (expanded_ast) else {}`.
- After: The same expression expands to `let xxx = expanded_ast else {}`.
An alternative solution to this issue could involve handling the source code directly when encountering unused parentheses in `let-init-else` expressions. However, this approach might be more cumbersome due to the absence of the necessary data structure.
r? `@petrochenkov`
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``
Clean up "const" situation in format_args!().
This cleans up the "const" situation in the format_args!() expansion/lowering.
Rather than marking the Argument::new_display etc. functions as non-const, this marks the Arguments::new_v1 functions as non-const.
Example expansion/lowering of format_args!() in const:
```rust
// Error: cannot call non-const formatting macro in constant functions
const {
fmt::Arguments::new_v1( // Now the error is produced here.
&["Hello, ", "!\n"],
&[
fmt::Argument::new_display(&world) // The error used to be produced here.
],
)
}
```
Decouple SCC annotations from SCCs
This rewires SCC annotations to have them be a separate, visitor-type data structure. It was broken out of #130227, which needed them to be able to remove unused annotations after computation without recomputing the SCCs themselves.
As a drive-by it also removes some redundant code from the hot loop in SCC construction for a performance improvement.
r? lcnr
shared-generics: Do not share instantiations that contain local-only types
In Zed shared-generics loading takes up a significant chunk of time in incremental build, as rustc deserializes rmeta of all dependencies of a crate. I've recently realized that shared-generics includes all instantiations of some_generic_function in the following snippet:
```rs
pub fn some_generic_function(_: impl Fn()) {}
pub fn non_generic_function() {
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
some_generic_function(|| {});
}
```
even though none of these instantiations can actually be created from outside of `non_generic_function`. This is a dummy example, but we do rely on invoking callbacks with FnOnce a lot in our codebase.
This PR makes shared-generics account for visibilities of generic arguments; an item is only considered for exporting if it is reachable from the outside or if all of it's arguments are visible outside of the local crate.
This PR reduces incremental build time for Zed (touch editor.rs scenario) from 12.4s to 10.4s. I'd love to see a perf run if possible; per my checks this PR does not incur new instantiations in downstream crates, so if there'd be perf regressions, I'd expect them to come from newly-introduced visibility checks.
Because RISC-V Calling Conventions note that:
> This means code targeting the Zfinx extension always uses the ILP32,
> ILP32E or LP64 integer calling-convention only ABIs as there is no
> dedicated hardware floating-point register file.
{ILP32,LP64}[FD] ABIs with hardware floating-point calling conventions
are incompatible with the "Zfinx" extension.
This commit adds "zfinx" to the incompatible feature list to those ABIs
and tests whether trying to add "zdinx" (that is analogous to "zfinx" but
in double-precision) on a LP64D ABI configuration results in an error
(it also tests extension implication; "Zdinx" requires "Zfinx" extension).
Link: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
Add a jobserver proxy to ensure at least one token is always held
This adds a jobserver proxy to ensure at least one token is always held by `rustc`. Currently with `-Z threads` `rustc` can temporarily give up all its tokens, causing `cargo` to spawn additional `rustc` instances beyond the job limit.
The current behavior causes an issue with `cargo fix` which has a global lock preventing concurrent `rustc` instances, but it also holds a jobserver token, causing a deadlock when `rustc` gives up its token. That is fixed by this PR.
Fixes https://github.com/rust-lang/rust/issues/67385.
Fixes https://github.com/rust-lang/rust/issues/133873.
Fixes https://github.com/rust-lang/rust/issues/140093.
This commit adds three ratified unprivileged RISC-V extensions related to
BFloat16 (BF16) handling.
Although that they are far from stabilization due to ABI issues, they are
optional extensions of the RVA23U64 profile (application-class processor
profile) and going to be discoverable from the Linux kernel
(as of version 6.15-rc4).
This commit mainly prepares runtime detection of those extensions.
This commit adds a part of RISC-V extensions that are mandatory part of
the RVA23U64 profile (application-class processor profile) and related to
memory/atomic constraints.
The Zic64b extension constrains the cache line to naturally-aligned 64 bytes
that would make certain memory operations (like zeroing the memory using
the Zicboz extension) easier.
The Zicbom and Zicbop extensions enable managing cache block-based
operations (the Zicbop contains hints that will work as a NOP when this
extension is absent and the Zicbom contains control instructions).
Of which, the Zicbom extension is going to be discoverable from the Linux
kernel (as of the version 6.15-rc4) and this commit prepares for
corresponding stdarch changes.
The Zicc* extensions add certain constraints to "the main memory" (usually
true on the user mode application on the application-class processor but
those extensions make sure such constraints exist).
The Za64rs extension (reservation set -- a primitive memory unit of LR/SC
atomic operations -- is naturally aligned and *at most* 64 bytes) is a
superset of the Za128rs extension (*at most* 128 bytes; note that smaller
the reservation set is, more fine grained control over atomics).
This commit handles this as a feature implication.
Drop AST on a separate thread and prefetch `hir_crate`
This drop AST on a separate thread and prefetches `hir_crate`.
A `spawn` function is added to the `parallel` module which spawn some work on the Rayon thread pool.
Don't FCW assoc consts in patterns
Fixes#140447
See comment in added test. We could also check that the anon const is a const arg by looking at the HIR. I'm not sure that's necessary though 🤔 The only consts that are evaluated "for the type system" are const args (which *should* get FCWs) and const patterns (which cant be anon consts afaik).
Replace use of rustc_type_ir by rustc_middle
cc #138449
I want to help on this issue. I have replaced all the rustc_type_ir uses by the equivalent type in rustc_middle.
DelayedSet is also re-exposed by rustc_middle.
transmutability: ensure_sufficient_stack when answering query
Based on #140380.
Fixes#118860. The compile time was addressed earlier, this merely addresses stack overflow part of the issue.
r? `@jswrenn` `@joshlf`
Issue an error when using `no_mangle` on language items
This pull requests adds the code to issue an error or a warning when using `no_mangle` on language items. This should detail why the `undefined symbol` error is issued for the code described in #139923.
The pull request adds two ui tests, one testing the error and the other one the warning.
I would love some feedback here, as I am not sure that the error and warning are issues using the right API.
Check bare function idents for non snake-case name
This PR adds the check required to lint on bare function idents for non snake-case name.
Reported at #140089.
cc `@theemathas`
This commit does the following:
- Replaces use of rustc_type_ir by rustc_middle
- Removes the rustc_type_ir dependency
- The DelayedSet type is exposed by rustc_middle so everything can be
accessed through rustc_middle in a coherent manner.
add suggestion on how to add a panic breakpoint
Co-authored-by: Pat Pannuto <pat.pannuto@gmail.com>
delete no_mangle from ui/panic-handler/panic-handler-wrong-location test
issue an error for the usage of #[no_mangle] on internal language items
delete the comments
add newline
rephrase note
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
update error not to leak implementation details
delete no_mangle_span
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
delete commented code
Rename `rustc_query_append!` to `rustc_with_all_queries!`
Whenever I'm trying to make sense of the query system internals, I always get tripped up on this unhelpfully-named macro. The fact that it's a higher-order proc macro is already mind-melting enough on its own.
This new name, `rustc_with_all_queries!`, forms a much more intuitive combination with the helper macros that it invokes. And only one of the call sites was even making use of the “append” part of its old name.
This PR also reformats the parameters matched by the helper macros, to make the actual argument syntax a bit easier to see.
---
Renaming and reformatting only; no functional changes.
rm `TypeVistable` impls for `Canonical`
similar to `EarlyBinder`, you generally do not want to fold a canonical value directly without first instantiating it. In places where you do want to look into the `Canonical`, it's likely better to do so manually.
r? ```@compiler-errors```
