Use better error message for hard errors in CTFE
I noticed this while working on #86255: currently the same message is used for hard errors and soft errors in CTFE. This changes the error messages to make hard errors use a message that indicates the reality of the situation correctly, since usage of the constant is never allowed when there was a hard error evaluating it. This doesn't affect the behaviour of these error messages, only the content.
This changes the error logic to check if the error should be hard or soft where it is generated, instead of where it is emitted, to allow this distinction in error messages.
Remove methods under Implementors on trait pages
As discussed at https://github.com/rust-lang/rust/issues/84326#issuecomment-842652412.
On a trait page, the "Implementors" section currently lists all methods of each implementor. That duplicates the method definitions on the trait itself, and is usually not very useful. So the implementors are collapsed by default. This PR changes rustdoc to just not render them at all. Any documentation specific to an implementor can be found by clicking through to the implementor's page.
This moves the "portability" info inside the `<summary>` tags so it is still visible on trait pages (as originally implemented in #79201). That also means it will be visible on struct/enum pages when methods are collapsed.
Add `#[doc(hidden)]` to all implementations of `Iterator::__iterator_get_unchecked` that didn't already have it. Otherwise, due to #86145, the structs/enums with those implementations would generate documentation for them, and that documentation would have a broken link into the Iterator page. Those links were already "broken" but not detected by the link-checker, because they pointed to one of the Implementors on the Iterator page, which happened to have the right anchor name.
This reduces the Read trait's page size from 128kB to 68kB (uncompressed) and from 12,125 bytes to 9,989 bytes (gzipped
Demo:
https://hoffman-andrews.com/rust/remove-methods-implementors/std/string/struct.String.html#trait-implementationshttps://hoffman-andrews.com/rust/remove-methods-implementors/std/io/trait.Read.html#implementors
r? `@GuillaumeGomez`
Rename IoSlice(Mut)::advance to advance_slice and add IoSlice(Mut)::advance
Also changes the signature of `advance_slice` to accept a `&mut &mut [IoSlice]`, not returning anything. This will better match the `IoSlice::advance` function.
Updates https://github.com/rust-lang/rust/issues/62726.
Replace parent substs of associated types with inference vars in borrow checker
Fixes https://github.com/rust-lang/rust/issues/83190
Fixes https://github.com/rust-lang/rust/issues/78450
When we normalize an associated type that refers to an opaque type, it can happen that the substs of the associated type do not occur in the projection (they are parent substs). We previously didn't replace those substs with inference vars, which left a concrete region after all regions should have already been replaced with inference vars and triggered a `delay_span_bug`. After we normalize the opaque type, we now try to replace any remaining concrete regions with inference vars.
Handle C-variadic arguments properly when reporting region errors
This pull request fixes#86053. The issue is that for a C-variadic function
```rust
#![feature(c_variadic)]
unsafe extern "C" fn foo(_: (), ...) {}
```
`foo`'s signature will contain only the first parameter (and have `c_variadic` set to `true`), whereas its body has a second argument (a `hir::Pat` for the `...`).
The code for reporting region errors iterates over the body's parameters and tries to fetch the corresponding parameter from the signature; this causes an out-of-bounds ICE for the `...` (though not in the example above, because there are no region errors to report).
I have simply restricted the iteration over the body parameters to exclude `...`, which is fine because `...` cannot cause a region error.
These were previously removed along with the details in the
"Implementors" section of trait pages. But for "Implementations on
Foreign Types," we need to include the details because they will not be
documented anywhere else.
That means it will be visible under "Implementors" on trait pages, and
under "Implementations" on struct/enum pages, even when all methods are
collapsed.
Switch to a float layout for rightside elements.
This method on the Iterator trait is doc(hidden), and about half of
implementations were doc(hidden). This adds the attribute to the
remaining implementations.
These were hidden by default, and duplicated information already on the
page anyhow.
Also remove the "Auto-hide trait implementors of a trait" setting,
which is not needed anymore.
The previous linking seemed confusing: within "the sum() method on
iterators", "sum()" was linked to `Sum::sum`, not `Iterator::sum`, even
though the sentence is talking about the latter.
I have rewritten the sentence to be, I believe, clearer, as well as
changing the link destinations; applying the same change to the
`Product` documentation as well as `Sum`.
The `RustdocGUI::should_run` condition spawns `npm list` several times
which adds up to seconds of wall-time.
Evaluate the condition lazily to to keep `./x.py test tidy` and similar
short-running tasks fast.
Stop returning a value from `report_assert_as_lint`
This function only ever returns `None`. Make that explicity by not returning a value at all.
`@rustbot` modify labels +C-cleanup +T-compiler
Open trait implementations' toggles by default.
This makes it possible to use Ctrl-F to find methods defined in traits.
As discussed in #85923. This modifies the approach suggested in #40363, but still achieves the goal of skimmability. For new users who aren't familiar with all the traits, their methods are readily visible and searchable. For experienced users who prefer to skim the list of all traits, there are two options: the "collapse all" shortcut, and the "auto hide trait implementations" setting.
Demo https://hoffman-andrews.com/rust/expand-methods/std/string/struct.String.html#trait-implementations
r? `@GuillaumeGomez`
Link reference in `dyn` keyword documentation
The "read more" sentence formatted "object safety" as inline code
instead of providing a link to more information. This PR adds a link
to the Reference about this matter, as well as the page regarding trait
objects.
---
We could also put these links in the very first line (instead of the link to the
Book) and in the first paragraph which mentions the "object safe" requirement.
Personally, I think it's good to keep the link to the Book up-front as it's more
accessible than the Reference.
Mention the `Borrow` guarantee on the `Hash` implementations for Arrays and `Vec`
To remind people like me who forget about it and send PRs to make them different, and to (probably) get a test failure if the code is changed to no longer uphold it.
Fix span calculation in format strings
This pull request fixes#86085. The ICE described there is due to an error in the span calculation inside format strings, if the format string is the result of a macro invocation:
```rust
fn main() {
format!(concat!("abc}"));
}
```
currently produces:
```
error: invalid format string: unmatched `}` found
--> test.rs:2:17
|
2 | format!(concat!("abc}"));
| ^ unmatched `}` in format string
```
which is obviously incorrect. This happens because the span of the entire `concat!()` is combined with the _relative_ location of the unmatched `` `}` `` in the _result_ of the macro invocation (i.e. 4).
In #86085, this has led to a span that starts or ends in the middle of a multibyte character, but the root cause was the same. This pull request fixes the problem.
Box `thir::ExprKind::Adt` for performance
`Adt` is the biggest variant in the enum and probably isn't used very often compared to the other expr kinds, so boxing it should be beneficial for performance. We need a perf test to be sure.
