Extend the existing tests for `f32` and `f64` with versions that include
`f16`'s new printing and parsing implementations.
Co-authored-by: Speedy_Lex <alex.ciocildau@gmail.com>
gvn: avoid creating overlapping assignments
Quick fix#141038, as I couldn't find a way to avoid in-place modification. I'm considering handling all `ravlue` modifications within the `visit_statement` function.
r? mir-opt
bump windows crate for compiler,bootstrap and tools
This dedupes crate versions. For `x86_64-pc-windows-msvc` stage1 cuts few kb from `rustc_driver.dll`, nice.
Return value of coroutine_layout fn changed to Result with LayoutError
Continue of https://github.com/rust-lang/rust/pull/140902:
`coroutine_layout` fn is now returns `Result` with `LayoutError` to have consistent error with `layout_of_uncached`.
`async_drop_coroutine_layout` fn is now return `LayoutError::TooGeneric` in case of not-fully-specialized `async_drop_in_place<T>::{closure}` coroutine.
name resolution for guard patterns
This PR provides an initial implementation of name resolution for guard patterns [(RFC 3637)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md). This does not change the requirement that the bindings on either side of an or-pattern must be the same [(proposal here)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md#allowing-mismatching-bindings-when-possible); the code that handles that is separate from what this PR touches, so I'm saving it for a follow-up.
On a technical level, this separates "collecting the bindings in a pattern" (which was already done for or-patterns) from "introducing those bindings into scope". I believe the approach used here can be extended straightforwardly in the future to work with `if let` guard patterns, but I haven't tried it myself since we don't allow those yet.
Tracking issue for guard patterns: #129967
cc ``@Nadrieril``
std: stop using TLS in signal handler
TLS is not async-signal-safe, making its use in the signal handler used to detect stack overflows unsound (c.f. #133698). POSIX however lists two thread-specific identifiers that can be obtained in a signal handler: the current `pthread_t` and the address of `errno`. Since `pthread_equal` is not AS-safe, `pthread_t` should be considered opaque, so for our purposes, `&errno` is the only option. This however works nicely: we can use the address as a key into a map that stores information for each thread. This PR uses a `BTreeMap` protected by a spin lock to hold the guard page address and thread name and thus fixes#133698.
split `asm!` parsing and validation
This PR splits `asm!` parsing and validation into two separate steps.
The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros.
The validation then checks things like ordering of arguments or that options are not provided twice.
The motivation is https://github.com/rust-lang/rust/issues/140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`.
An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable https://github.com/rust-lang/style-team/issues/152).
r? ``@ghost`` (just want to look at CI for now)
cc ``@ytmimi`` we discussed asm formatting a little while ago in https://github.com/rust-lang/rustfmt/issues/6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before?
try-job: aarch64-apple
Stabilize the avx512 target features
This PR stabilizes the AVX512 target features - see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2745821279).
Tracking Issue - #44839
The target feature UI tests have been changed to `x87` (chosen because this is very unlikely to stablize ever, please comment if some other feature will be better)
related: #111137
Use the existing Lemire (decimal -> float) and Dragon / Grisu algorithms
(float -> decimal) to add support for `f16`. This allows updating the
implementation for `Display` to the expected behavior for `Display`
(currently it prints the a hex bitwise representation), matching other
floats, and adds a `FromStr` implementation.
In order to avoid crashes when compiling with Cranelift or on targets
where f16 is not well supported, a fallback is used if
`cfg(target_has_reliable_f16)` is not true.
[win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test
PR #140758 added the undocumented `/arm64hazardfree` MSVC linker flag to work around a test failure where LLVM generated code that would trip a hazard in an outdated ARM processor.
Adding this flag caused issues with LLD, as it doesn't recognize it.
Rethinking the issue, using the undocumented flag seems like the incorrect solution: there's no guarantee that the flag won't be removed in the future, or change its meaning.
Instead, I've disabled the problematic test for Arm64 Windows and have filed a bug with the MSVC team to have the check removed: <https://developercommunity.microsoft.com/t/Remove-checking-for-and-fixing-Cortex-A/10905134>
This PR supersedes #140977
r? ```@jieyouxu```
Remove #![feature(let_chains)] from library and src/librustdoc
PR https://github.com/rust-lang/rust/pull/132833 has stabilized the `let_chains` feature. This PR removes the last occurences from the library, the compiler, and librustdoc (also because #140887 missed the conditional in one of the crates as it was behind the "rustc" feature).
We keep `core` as exercise for the future as updating it is non-trivial (see PR thread).
