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).
Add per page TOC in the `rustc` book
This PR adds per page Table of Content (TOC) in the `rustc` book (to be extended in the future to our other books).
The goal is to easy the navigation inside the page by providing quick overview of the page content and our position inside that page.
That functionality is unfortunately not available natively in `mdbook`, which prompted community members to create [mdBook-pagetoc](https://github.com/JorelAli/mdBook-pagetoc/) (which this PR is heavily inspired by). It's "only" a JS file (to handle the TOC) and a CSS file (to handle the margin, colors, screen size, ...), there is no "post-processor" needed (in mdbook sense).
Live preview at: http://urgau.rf.gd/book
r? ```@jieyouxu```
Fast path for `register_region_obligation`
If a type has no params, infer, placeholder, or non-`'static` free regions, then we can skip registering outlives obligations since the type has no components which affect lifetime checking in an interesting way.
