Improve type mismatch error messages
Closes#56115.
Replace "integral variable" with "integer" and replace "floating-point variable" with "floating-point number" to make the message less confusing.
TODO the book and clippy needs to be changed accordingly later.
r? @varkor
privacy: Use common `DefId` visiting infrastructure for all privacy visitors
One repeating pattern in privacy checking is going through a type, visiting all `DefId`s inside it and doing something with them.
This is the case because visibilities and reachabilities are attached to `DefId`s.
Previously various privacy visitors visited types slightly differently using their own methods, with most recently written `TypePrivacyVisitor` being the "gold standard".
This mostly worked okay, but differences could manifest in overly conservative reachability analysis, some errors being reported twice, some private-in-public lints (not errors) being wrongly reported or not reported.
This PR does something that I wanted to do since https://github.com/rust-lang/rust/pull/32674#discussion_r58291608 - factoring out the common visiting logic!
Now all the common logic is contained in `struct DefIdVisitorSkeleton`, with specific privacy visitors deciding only what to do with visited `DefId`s (via `trait DefIdVisitor`).
A bunch of cleanups is also applied in the process.
This area is somewhat tricky due to lots of easily miss-able details, but thankfully it's was well covered by tests in https://github.com/rust-lang/rust/pull/46083 and previous PRs, so I'm relatively sure in the refactoring correctness.
Fixes https://github.com/rust-lang/rust/pull/56837#discussion_r241962239 in particular.
Also this will help with implementing https://github.com/rust-lang/rust/issues/48054.
Implement RFC 2338, "Type alias enum variants"
This PR implements [RFC 2338](https://github.com/rust-lang/rfcs/pull/2338), allowing one to write code like the following.
```rust
#![feature(type_alias_enum_variants)]
enum Foo {
Bar(i32),
Baz { i: i32 },
}
type Alias = Foo;
fn main() {
let t = Alias::Bar(0);
let t = Alias::Baz { i: 0 };
match t {
Alias::Bar(_i) => {}
Alias::Baz { i: _i } => {}
}
}
```
Since `Self` can be considered a type alias in this context, it also enables using `Self::Variant` as both a constructor and pattern.
Fixes issues #56199 and #56611.
N.B., after discussing the syntax for type arguments on enum variants with @petrochenkov and @eddyb (there are also a few comments on the [tracking issue](https://github.com/rust-lang/rust/issues/49683)), the consensus seems to be treat the syntax as follows, which ought to be backwards-compatible.
```rust
Option::<u8>::None; // OK
Option::None::<u8>; // OK, but lint in near future (hard error next edition?)
Alias::<u8>::None; // OK
Alias::None::<u8>; // Error
```
I do not know if this will need an FCP, but let's start one if so.
AST/HIR: Introduce `ExprKind::Err` for better error recovery in the front-end
This way we can avoid aborting compilation if expansion produces errors and generate `ExprKind::Err`s instead.
- Point at opening mismatched formatting brace
- Account for differences between raw and regular strings
- Account for differences between the code snippet and `InternedString`
- Add more tests
make non_camel_case_types an early lint
This allows us to catch these kinds of style violations much earlier, as evidenced by the large number of tests that had to be updated for this change.
enum type instead of variant suggestion unification
Fixes#56028.
Weirdly, we were deciding between a help note and a structured suggestion based on whether the import candidate span was a dummy—but we weren't using that span in any case! The dummy-ness of the span (which appears to be a matter of this-crate vs. other-crate definition) isn't the right criterion by which we should decide whether it's germane to mention that "there is an enum variant"; instead, let's use the someness of `def` (which is used as the `has_unexpected_resolution` argument to `error_code`).
Since `import_candidate_to_paths` has no other callers, we are free to stop returning the span and rename the function. By using `span_suggestions_`, we leverage the max-suggestions output limit already built in to the emitter, thus resolving #56028.
In the matter of message wording, "you can" is redundant (and perhaps too informal); prefer the imperative.
In a second commit, we do some unprincipled special-casing to correct and beautify suggestions for `Option` and `Result` (where the existing code was being confused by their being reexported in the prelude).
r? @davidtwco
Weirdly, we were deciding between a help note and a structured
suggestion based on whether the import candidate span was a dummy—but
we weren't using that span in any case! The dummy-ness of the span
(which appears to be a matter of this-crate vs. other-crate
definition) isn't the right criterion by which we should decide
whether it's germane to mention that "there is an enum variant";
instead, let's use the someness of `def` (which is used as the
`has_unexpected_resolution` argument to `error_code`).
Since `import_candidate_to_paths` has no other callers, we are free to
stop returning the span and rename the function. By using
`span_suggestions_`, we leverage the max-suggestions output limit
already built in to the emitter, thus resolving #56028.
In the matter of message wording, "you can" is redundant (and perhaps
too informal); prefer the imperative.
Update migrate warning wording.
This PR modifies the wording of the warning for backwards-incompatible changes in migrate mode. The warning messages are changed to be lowercase and not include line-breaks in order to be consistent with other compiler diagnostics.
static eval: Do not ICE on layout size overflow
Layout size overflow and typeck eval errors are reported. Trigger a bug
only when the eval error is strictly labeled as TooGeneric.
Fixes: #56762
This commit modifies the wording of the warning for
backwards-incompatible changes in migrate mode. The warning messages are
changed to be lowercase and not include line-breaks in order to be
consistent with other compiler diagnostics.
Fix various aspects around `let` bindings inside const functions
* forbid `let` bindings in const contexts that use short circuiting operators
* harden analysis code against derefs of mutable references
Initially this PR was about stabilizing `let` bindings, but too many flaws were exposed that need some more testing on nightly
add coherence future-compat warnings for marker-only trait objects
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
Note: this lint should be made to default-warn before we merge. It is deny only for the crater run.
r? @nikomatsakis / @scalexm . cc @Centril & @alexreg.
