There is a weak convention in the ecosystem that `IterFoos` is an
iterator yielding items of type `Foo` (e.g. `bitflags` `IterNames`,
`hashbrown` `IterBuckets`), while `FooIter` is an iterator over `Foo`
from an `.iter()` or `.into_iter()` method (e.g. `memchr` `OneIter`,
`regex` `SetMatchesIter`). Rename `IterRange`, `IterRangeInclusive`, and
`IterRangeFrom` to `RangeIter`, `RangeInclusiveIter`, and
`RangeInclusiveIter` to match this.
Tracking issue: RUST-125687 (`new_range_api`)
Tidying up UI tests [7/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
removed directory `tests/ui/explicit`, `tests/ui/interior-mutability`, `tests/ui/invalid-module-declaration`, tests/ui/invalid-self-argument`
r? Kivooeo
make assoc fn inherit const stability from inherent `const impl` blocks
Pulled out of rust-lang/rust#147893, "Currently, one cannot add any const stability annotations on the individual assoc fns at all, as the specific pass that checks for const stability on const fn seems to run as a HIR visitor [and looks at HIR assoc fn constness, which should be changed to also look at its parent]. I suspect there are things to be cleaned up there."
I was slightly lazy so didn't add the "staged_api using staged_api in implicit const stable context, in const unstable context, in explicit const stable context" tests. nudge me if you want to see those!
Don't suggest unwrap for Result in const
closerust-lang/rust#149316
Regarding `const fn` that returns `Result`, we should avoid suggesting unwrapping. The original issue reported cases where types didn't match, but in practice, such suggestions may also appear when methods are not found, so this PR includes a fix for that case as well.
cmse: do not calculate the layout of a type with infer types
tracking issue: https://github.com/rust-lang/rust/issues/81391
tracking issue: https://github.com/rust-lang/rust/issues/75835
fixes https://github.com/rust-lang/rust/issues/130104
Don't calculate the layout of a type with an infer type (`_`). This now emits `LayoutError::Unknown`, causing an error similar to when any other calling convention is used in this location.
The tests use separate functions because only the first such error in a function body is reported.
r? `@davidtwco` (might need some T-types assistance)
coverage: Store signature/body spans and branch spans in the expansion tree
In order to support coverage instrumentation of expansion regions, we need to reduce the amount of code that assumes we're only instrumenting a flat function body. Moving more data into expansion tree nodes is an incremental step in that direction.
There should be no change to compiler output.
Fix bad intra-doc-link preprocessing
How did rust-lang/rust#147981 happen?
1. We don't parse intra-doc links as Rust paths or qpaths. Instead they follow a very lenient bespoke grammar. We completely ignore Markdown links if they contain characters that don't match `/[a-zA-Z0-9_:<>, !*&;]/` (we don't even emit lint *broken-intra-doc-links* for these).
2. PR [#132748](https://github.com/rust-lang/rust/pull/132748) made rustdoc intepret more Markdown links as potential intra-doc links. Namely, if the link is surrounded by backticks (and some other conditions apply) then it doesn't matter if the (partially processed) link contains bad characters as defined above (cc `ignore_urllike && should_ignore_link(path_str)`).
3. However, rustdoc's `preprocess_link` must be kept in sync with a simplified counterpart in rustc. More specifically, whenever rustdoc's preprocessor returns a successful result then rustc's must yield the same result. Otherwise, rustc doesn't resolve the necessary links for rustdoc.
4. This uncovered a "dormant bug" / "mistake" in rustc's `preprocess_link`. Namely, when presented with a link like `struct@Type@suffix`, it didn't cut off the disambiguator if present (here: `struct@`). Instead it `rsplit('``@')``` which is incorrect if the "path" contains ```@``` itself (yielding `suffix` instead of `Type@suffix` here). Prior to PR [#132748](https://github.com/rust-lang/rust/pull/132748), a link like ``[`struct@Type@suffix`]`` was not considered a potential intra-doc link / worth querying rustc for. Now it is due to the backticks.
5. Finally, since rustc didn't record a resolution for `Type@suffix` (it only recorded `suffix` (to be `Res::Err`)), we triggered an assertion we have in place to catch cases like this.
Fixesrust-lang/rust#147981.
I didn't and still don't have the time to investigate if rust-lang/rust#132748 led to more rustc/rustdoc mismatches (after all, the PR made rustdoc's `preprocess_link` return `Some(Ok(_))` in more cases). I've at least added another much needed "warning banner" & made the existing one more flashy.
While this fixes a stable-to-beta regression, I don't think it's worth beta backporting, esp. since it's only P-medium and since the final 1.91 release steps commence today / the next days, so it would only be stressful to get it in on time. However, feel free to nominate.
<sub>(I've written such a verbose PR description since I tend to reread my old PR descriptions in the far future to fully freshen my memories when I have to work again in this area)</sub>
r? ``@lolbinarycat``
float::min/max: reference NaN bit pattern rules
Also, the "in particular" transition to the signed zero handling was odd, so I rearranged things a bit: first a self-contained description of the semantics, then an explanation of which operations in other standards/libraries this most closely corresponds to.
r? `@tgross35`
