Suggest appropriate path when calling associated item on bare types
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.
Fix#26760, fix#46660.
implement specialized nth_back() for Bytes, Fuse and Enumerate
Hi,
After my first PR has been successfully merged, here is my second pull request :-)
Also this PR contains some specializations for the problem discussed in #54054.
Implement event filtering for self-profiler.
This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from https://github.com/rust-lang/rust/pull/59515 and, for the moment, is meant for performance testing.
r? @wesleywiser
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
