When looking at the documentation for `std::f32` or `std::str`, for
example, it is easy to get confused and assume `std::f32` and `f32`
are the same thing. Because of this, it is not uncommon to attempt
writing `f32::consts::PI` instead of the correct
`std::f32::consts::PI`. When encountering the former, which results
in an access error due to it being an inexistent path, try to access
the same path under `std`. If this succeeds, this information is
stored for later tweaking of the final E0599 to provide an
appropriate suggestion.
This suggestion applies to both E0233 and E0599 and is only checked
when the first ident of a path corresponds to a primitive type.
Rename files about error codes
fixes#60017
This PR will be failed in tidy.
<details>
<summary>The log is here:</summary>
```
tidy check
tidy error: duplicate error code: 411
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:83: __diagnostic_used!(E0411);
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:84: err.code(DiagnosticId::Error("E0411".to_owned()));
tidy error: duplicate error code: 424
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:90: debug!("smart_resolve_path_fragment: E0424, source={:?}", source);
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:92: __diagnostic_used!(E0424);
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:93: err.code(DiagnosticId::Error("E0424".to_owned()));
some tidy checks failed
```
</details>
I'd like to fix this but I don't know what to do.
I will work on later. Please let me know if you have any solutions.
r? @petrochenkov
The documentation for `rchunks_exact` said it started at the beginning
of the slice, bit it actually starts at the end of the slice.
In addition, there were a couple of "of the slice of the slice"
duplicate phrases going on for `rchunks_exact` and `rchunks_exact_mut`.
This fixes#60068.
Resolve inconsistency in error messages between "parameter" and "variable".
The inconsistency was introduced in 104fe1c4db (#33619), when a label saying `type variable` was added to an error with a message talking about `type parameters`.
Given that `parameter` is far more prevalent when referring to generics in the context of Rust, IMO it should be that in both the message and the label.
r? @nikomatsakis or @estebank
Remove collection-specific `with_capacity` documentation from `std::collections`
Fixes#59931
The style of `std::collections` module doc is very much a beginner friendly guide, and documenting niche, collection-specific behaviour feels out of place, if not brittle.
The note about `VecDeque` is outdated (see issue), and while `Vec` probably won't change its guarantees any time soon, the users who are interested in its allocation properties will find that in its own documentation.
Add test checking that Index<T: ?Sized> works
I've noticed that we have an `Idx: ?Sized` bound on the **index** in the `Index`, which seems strange given that we accept index by value. My guess is that it was meant to be removed in https://github.com/rust-lang/rust/pull/23601, but was overlooked.
If I remove this bound, `./x.py src/libstd/ src/libcore/` passes, which means at least that this is not covered by test.
I think there's three things we can do here:
* run crater with the bound removed to check if there are any regressions, and merge this, to be consistent with other operator traits
* run crater, get regressions, write a test for this with a note that "hey, we tried to fix it, its unfixable"
* decide, in the light of by-value DSTs, that this is a feature rather than a bug, and add a test
cc @rust-lang/libs
EDIT: the forth alternative is that there exist a genuine reason why this is the case, but I failed to see it :D
