Clean up or resolve cfg-related instances of `FIXME(f16_f128)`
* Replace target-specific config that has a `FIXME` with `cfg(target_has_reliable_f*)`
* Take care of trivial intrinsic-related FIXMEs
* Split `FIXME(f16_f128)` into `FIXME(f16)`, `FIXME(f128)`, or `FIXME(f16,f128)` to more clearly identify what they block
The individual commit messages have more details.
update enzyme, includes an extra patch to fix MacOS builds in CI
I updated the submodule under rust-lang/enzyme to match EnzymeAD/enzyme, and added one commit, which based on some testing should fix how we build Enzyme in the MacOS CI. Once this pr landed, we will verify again that CI still works, and afterwards upstream the patch and drop it from our fork. No new test failures.
cc @sgasho
r? @Kobzol
Rename `HandleCycleError` to `CycleErrorHandling`
In https://github.com/rust-lang/rust/pull/101303, the `handle_cycle_error` field was changed from a macro-generated closure to a macro-selected enum variant. But it was not renamed to reflect the fact that it now holds data, not code.
Renaming the field and its associated enum to `cycle_error_handling: CycleErrorHandling` should make the relevant code less confusing to read.
This PR also moves the enum out of `rustc_query_system::error`, where it was easily confused with diagnostic structs.
There should be no change to compiler behaviour.
Add -Z large-data-threshold
This flag allows specifying the threshold size for placing static data in large data sections when using the medium code model on x86-64.
When using -Ccode-model=medium, data smaller than this threshold uses RIP-relative addressing (32-bit offsets), while larger data uses absolute 64-bit addressing. This allows the compiler to generate more efficient code for smaller data while still supporting data larger than 2GB.
This mirrors the -mlarge-data-threshold flag available in GCC and Clang. The default threshold is 65536 bytes (64KB) if not specified, matching LLVM's default behavior.
inline constant localized typeck constraint computation
This fixes an oversight in the previous PRs, this constraint is local to a point (and liveness does the rest) and so has a fixed direction.
I wasn't planning on trying to improve the impl for perf, versus computing loan liveness without first unifying the cfg and subset graph, but it's like a 20x improvement for typeck constraints on wg-grammar (-15% end-to-end) for a trivial fix.
r? @jackh726
In general, I want to cleanup these edges to avoid off-by-one errors in constraints at effectful statements and ensure the midpoint-avoidance strategy is sound and works well, in particular with respect to edges that flow backwards from the result into its inputs. But I'd like to start from something that passes all tests and is simpler, because the eventual solution may
1. involve localizing these edges differently than *separate* liveness and typeck lowering passes/approaches, which would need to be lowered at the same time for example. I'm already doing the latter in the loan liveness rewrite as part of creating edges on-demand during traversal, and this new structure would be a better fit to verify, or fix, these subtle edges.
2. also require changes in MIR typeck to track the flow across points more precisely, and I don't know how hard that would be. *Computing* the constraint direction is currently a workaround for that.
Therefore, in a future PR, I'll also remove this computation from the terminator constraints, but I can also do that in this PR if you'd prefer.
This FIXME was introduced in 6e2d934a88 ("Add more `f16` and `f128`
library functions and constants") but I can't actually find my
reasoning. As far as I can tell, LLVM has been lowering `fabs.f128` as
bitwise operations for a while across all targets so there shouldn't be
a problem here.
Thus, apply what is suggested in the FIXME.
There are a number of instances of `FIXME(f16_f128)` related to target
configuration; either these could use `target_has_reliable_f128`, or the
FIXME is describing such a cfg and is thus redundant (since any
`cfg(target_has_reliable_f*)` needs to be removed before stabilization
anyway).
Switch to using `target_has_reliable_*` where applicable and remove the
redundant FIXMEs.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#151450 (std: use `clock_nanosleep` for `sleep` where available)
- rust-lang/rust#151494 (std: ensure that the deadline has passed in `sleep_until`)
- rust-lang/rust#151498 (global.rs: improve readability of re-entrance section)
- rust-lang/rust#151504 (Reorganizing tests/ui/issues 11 tests [3/N])
r? @ghost
std: use `clock_nanosleep` for `sleep` where available
`nanosleep` is specified to use `CLOCK_REALTIME` but the documentation (especially the example) for `sleep` imply that it measures time using `Instant`, which uses `CLOCK_MONOTONIC`. Thus, this PR makes `sleep` use a relative `clock_nanosleep` with `CLOCK_MONOTONIC` where available. This doesn't make a difference for Linux (which uses `CLOCK_MONOTONIC` for `nanosleep` anyway) but is relevant for e.g. FreeBSD.
This also restores nanosecond-sleep precision for WASI, since https://github.com/rust-lang/rust/issues/150290 was caused by `nanosleep` internally using `clock_nanosleep` with `CLOCK_REALTIME` which is unsupported on WASIp2.
CC @alexcrichton for the WASI fix
Fix ICE when using zero-length SIMD type in extern static
before my fix using a zero-length SIMD type in an extern static would cause an internal compiler error. now it properly shows a diagnostic error instead of panicking. it was because `LayoutError::InvalidSimd` wasn't handled in `check_static_inhabited` and fell through to a generic `delayed_bug`.
i added handling for `InvalidSimd` in `check_static_inhabited` (similar to `SizeOverflow`): when a SIMD type has an invalid layout, we call `emit_err` with `Spanned` to emit a normal error instead of an ICE. compiler now emits a clear error `"the SIMD type Simd<u8, 0> has zero elements"` with the correct span on the type, matching expected compiler behavior.
fixesrust-lang/rust#151451
Previously, using a zero-length SIMD type in an extern static would
cause an internal compiler error. Now it properly emits a diagnostic
error instead of panicking.
Avoid `-> ()` in derived functions.
`hash` and `assert_receiver_is_total_eq` have no return type. This commit removes the `-> ()` that is currently printed for them.
r? @Kobzol
llvm: Tolerate dead_on_return attribute changes
The attribute now has a size parameter and sorts differently. Adjust tests to tolerate this.
https://github.com/llvm/llvm-project/pull/171712
r? durin42
@rustbot label llvm-main
fix `f16` doctest FIXMEs
tracking issue: https://github.com/rust-lang/rust/issues/116909
Remove a bunch of fixmes, and run docs tests on all targets that (should) support them.
r? tgross35
codegen: clarify some variable names around function calls
I looked at rust-lang/rust#145932 to try to understand how it works, and quickly got lost in the variable names -- what refers to the caller, what to the callee? So here's my attempt at making those more clear. Hopefully the new names are correct.^^
Cc @JamieCunliffe
Fix ICE: Don't try to evaluate type_consts when eagerly collecting items
This fixes https://github.com/rust-lang/rust/issues/151246
The change is pretty straightforward if the Monomorphization strategy is eager which `-Clink-dead-code=true` sets. This then would lead to the existing code to try and evaluate a `type const` which does not have a body to evaluate leading to an ICE. The change is pretty straight forward just skip over type consts.
This also seems like a sensible choice to me since a MonoItem can only be a Fn, Static, or Asm. A type const is none of the aforementioned.
And even if it was added to the MonoItems list it would then later fail this check:
fe98ddcfcf/compiler/rustc_monomorphize/src/collector.rs (L438-L440)
Since that explicitly checks that the MonoItem's `DefKind` is static and not anything else.
One more change is the addition of a simple test of the example code from https://github.com/rust-lang/rust/issues/151246 that checks that code compiles successfully with `-Clink-dead-code=true`.
The only other change was to make the guard checks a little easier to read by making the logic more linear instead of one big if statement.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
MGCA: Fix incorrect pretty printing of valtree arrays
Fixesrust-lang/rust#151126
- **add failing test**
- **fix: additional check whether const array could be printed as raw bytes**
As I figured out, the problem was in `pretty_print_const_valtree`, where it tried to print unevaluated consts as if they were evaluated, which resulted in ICE.
Handle unevaluated ConstKind in in_operand
fix: rust-lang/rust#151248
r? BoxyUwU
~~I can't reproduce rust-lang/rust#151246 in my local(x86_64-pc-windows-msvc) even before this change. 🤔
create a draft and test it in different environments.~~
fix fallback impl for select_unpredictable intrinsic
`intrinsics::select_unpredictable` does not drop the value that is not selected, but the fallback impl did not consider this behavior. This creates an observable difference between Miri and actual execution, and possibly does not play well with the `core::hint` version which has extra logic to drop the value that was not selected.
```rust
#![feature(core_intrinsics)]
fn main() {
core::intrinsics::select_unpredictable(true, LoudDrop(0), LoudDrop(1));
// cargo run: "0"; cargo miri run: "1 0"
}
struct LoudDrop(u8);
impl Drop for LoudDrop {
fn drop(&mut self) {
print!("{} ", self.0);
}
}
```
This change let me remove the `T: [const] Destruct` bound as well, since the destructor is no longer relevant.
rustdoc: render doc(hidden) as a code attribute
Move `#[doc(hidden)]` into the shared code-attribute renderer so it matches the styling and placement of other attributes in rustdoc HTML.
Closesrust-lang/rust#132304
