| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove "here" from "expected one of X here"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
|
|
|
|
|
|
r=matthewjasper
Add long error explanation for E0574
Part of #61137.
|
|
Bring attention to suggestions when the only difference is capitalization
CC #65386.
|
|
|
|
|
|
|
|
|
|
The constructor is private, not the type.
Idea credit to @petrochenkov, discussed at #65153
|
|
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>
|
|
Point at definition when misusing ADT
When given `struct Foo(usize)` and using it as `Foo {}` or `Foo`, point at `Foo`'s definition in the error.
|
|
Add Long error explanation for E0531
Part of #61137.
|
|
|
|
When given `struct Foo(usize)` and using it as `Foo {}` or `Foo`, point at
`Foo`'s definition in the error.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
jakubadamw:resolve-inconsistent-names-suggest-qualified-path, r=petrochenkov
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.
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
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.
|
|
|
|
Make the `is_import` flag in `ScopeSet` independent from namespace
Fix rebase
|
