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.
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
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
compiletest normalization: preserve non-JSON lines such as ICEs
Currently, every non-JSON line from stderr gets normalized away when compiletest normalizes the output. In particular, ICEs get normalized to the empty output. That does not seem desirable, so this changes normalization to preserve non-JSON lines instead.
Also see https://github.com/laumann/compiletest-rs/issues/169: because of that bug, Miri currently *looks* green in the toolstate, but some tests ICE. That same bug is likely no longer present in latest compiletest because the error code gets checked separately, but it still seems like a good idea to also make sure that ICEs are considered stderr output:
This change found an accidental user-visible `error!` in CTFE validation (fixed), and a non-deterministic panic when there are two `main` symbols (not fixed, no idea where this comes from). Both got missed before because non-JSON output got ignored.
Properly parse '--extern-private' with name and path
It turns out that https://github.com/rust-lang/rust/pull/57586 didn't properly parse `--extern-private name=path`.
This PR properly implements the `--extern-private` option. I've added a new `extern-private` option to `compiletest`, which causes an `--extern-private` option to be passed to the compiler with the proper path.
Part of https://github.com/rust-lang/rust/issues/44663
Fix cross-crate visibility of fictive variant constructors
After merging https://github.com/rust-lang/rust/pull/59376 I realized that the code in the decoder wasn't entirely correct - we "decoded" fictive variant constructors with their variant's visibility, which could be public, rather than demoted to `pub(crate)`.
Fictive constructors are not directly usable in expression/patterns, but the effect still can be observed with imports.
r? @davidtwco
