Update browser-ui-test version used in CI
I realized that the extension of `assert-text*` commands was generated not completely valid (it stopped at first "success" and moved instead of running all checks). It was fixed in [this PR](https://github.com/GuillaumeGomez/browser-UI-test/pull/280).
We don't use this feature currently in the rustdoc GUI tests, but just in case...
r? ``@notriddle``
Fix exposing fields marked unstable or doc hidden
Closes https://github.com/rust-lang/rust/issues/89837
Work towards https://github.com/rust-lang/rust/issues/89554
Filter fields that are marked `doc(hidden)` or are unstable with that feature turned off. This brings structs and enums into alignment behavior-wise when emitting warning/errors about pattern exhaustiveness/reachability.
cc `@Nadrieril`
Return early to fix ICE
This fixes#94627, ICE happens because compiler tries to suggest constraining type parameter but the only constraint is implicit `std::Sized` one, so it gets removed and there is nothing to suggest resulting in ICE.
diagnostics: do not spurriously claim something is "not an iterator"
Fixes a minor regression caused by #94746, where `iter::Filter` is spurriously declared "not an iterator."
rustdoc-json: Include GenericParamDefKind::Type::synthetic in JSON
The rustdoc JSON for
```
pub fn f(_: impl Clone) {}
```
will effectively be
```
pub fn f<impl Clone: Clone>(_: impl Clone) {}
```
where a synthetic generic parameter called `impl Clone` with generic trait bound
`Clone` is added to the function declaration.
The generated HTML filters out these generic parameters by doing
`self.params.iter().filter(|p| !p.is_synthetic_type_param())`, because the
synthetic generic paramter is not of interest to regular users.
For the same reason, we should expose whether or not a generic parameter is
synthetic or not also in the rustdoc JSON, so that rustdoc JSON clients can also
have the option to hide syntehtic generic parameters.
`@rustbot` modify labels: +A-rustdoc-json
Improve `AdtDef` interning.
This commit makes `AdtDef` use `Interned`. Much of the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.
r? `@fee1-dead`
Make float parsing docs more comprehensive
I was working on some code with some specialized restrictions on float parsing. I noticed the doc comments for `f32::from_str` and `f64::from_str` were missing several cases of valid inputs that are otherwise difficult to discover without looking at source code.
I'm not sure if the doc comments were initially intended to contain a comprehensive description of valid inputs, but I figured it's useful to include these extra cases for reference.
CTFE/Miri: detect out-of-bounds pointers in offset_from
Also I became uneasy with aggressively doing `try_to_int` here -- this will always succeed on Miri, leading to the wrong codepath being taken. We should rather try to convert them both to pointers, and use the integer path as a fallback, so that's what I implemented now.
Hiding whitespaces helps with the diff.
Fixes https://github.com/rust-lang/miri/issues/1950
r? ``@oli-obk``
Rename `IntoFuture::Future` to `IntoFuture::IntoFuture`
Ref: https://github.com/rust-lang/rust/issues/67644#issuecomment-1051401459
This renames `IntoFuture::Future` to `IntoFuture::IntoFuture`. This adds the `Into*` prefix to the associated type, similar to the [`IntoIterator::IntoIter`](https://doc.rust-lang.org/std/iter/trait.IntoIterator.html#associatedtype.IntoIter) associated type. It's my mistake we didn't do so in the first place. This fixes that and brings the two closer together. Thanks!
### References
__`IntoIterator` trait def__
```rust
pub trait IntoIterator {
type Item;
type IntoIter: Iterator<Item = Self::Item>;
fn into_iter(self) -> Self::IntoIter;
}
```
__`IntoFuture` trait def__
```rust
pub trait IntoFuture {
type Output;
type IntoFuture: Future<Output = Self::Output>; // Prior to this PR: `type Future:`
fn into_future(self) -> Self::IntoFuture;
}
```
cc/ `@eholk` `@rust-lang/wg-async`
