Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
Improve message when attempting to instantiate tuple structs with private fields
Fixes#58017, fixes#39703.
```
error[E0603]: tuple struct `Error` is private
--> main.rs:22:16
|
2 | pub struct Error(usize, pub usize, usize);
| ----- ----- field is private
| |
| field is private
...
22 | let x = a::Error(3, 1, 2);
| ^^^^^
|
= note: a tuple struct constructor is private if any of its fields is private
```
This commit modifies resolve to disallow foreign statics that use
parent generics.
`improper_ctypes` is not written to support type parameters, as these
are normally disallowed before the lint is run. Thus, type parameters in
foreign statics must be prohibited before the lint.
The only other case where this *could* have occured is in functions,
but typeck prohibits this with a "foreign items may not have type
parameters" error - a similar error did not exist for statics, because
statics cannot have type parameters, but they can use any
type parameters that are in scope (which isn't the case for functions).
Signed-off-by: David Wood <david@davidtw.co>
Unfortunately, the diagnotic machinery does not cope well with an empty
span which can happen if the crate is empty, in which case we merely set
a spanless note.
Suggest using a qualified path in patterns with inconsistent bindings
A program like the following one:
```rust
enum E { A, B, C }
fn f(x: E) -> bool {
match x {
A | B => false,
C => true
}
}
```
is rejected by the compiler due to `E` variant paths not being in scope.
In this case `A`, `B` are resolved as pattern bindings and consequently
the pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The help note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
it is the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the `non-camel-case-types` lint.
Fixes#50831.
A program like the following one:
```rust
enum E { A, B, C }
fn f(x: E) -> bool {
match x {
A | B => false,
C => true
}
}
```
is rejected by the compiler due to `E` variant paths not being in scope.
In this case `A`, `B` are resolved as pattern bindings and consequently
the pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the `non-camel-case-types` lint.
Move `Resolver` fields specific to late resolution to the new visitor.
The `current_module` field from `Resolver` is replaced with two `current_module`s in `LateResolutionVisitor` and `BuildReducedGraphVisitor`.
Outside of those visitors `current_module` is replaced by passing `parent_scope` to more functions and using the parent module from it.
Visibility resolution no longer have access to later resolution methods and has to use early resolution, so its diagnostics in case of errors regress slightly.
