Rename some `name` variables as `ident`.
It bugs me when variables of type `Ident` are called `name`. It leads to silly things like `name.name`. `Ident` variables should be called `ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of `Ident` variables. Not all of them, but a decent chunk.
r? `@fee1-dead`
It bugs me when variables of type `Ident` are called `name`. It leads to
silly things like `name.name`. `Ident` variables should be called
`ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of
`Ident` variables. Not all of them, but a decent chunk.
UI tests: add missing diagnostic kinds where possible
The subset of https://github.com/rust-lang/rust/pull/139427 that only adds diagnostic kinds to line annotations, without changing any other things in annotations or compiletest.
After this only non-viral `NOTE`s and `HELP`s should be missing.
r? `@jieyouxu`
Note potential but private items in show_candidates
Closes#138626 .
We should add potential private items to give ample hints.
And for the other seemingly false positive ` pub use crate:1️⃣:Foo;` should be kept because we don't know if the user wants to import other module's items or not, and therefore should be given the full option to do so.
r? compiler
Suggest replacing `.` with `::` when encountering "expected value, found enum":
- in a method-call expression and the method has the same name as a tuple variant
- in a field-access expression and the field has the same name as a unit or tuple variant
When `Foo.field` or `Foo.method()` exprs are encountered, suggest `Foo::field` or `Foo::method()` when Foo is a type alias, not just
a struct, trait, or module.
Also rename test for this suggestion from issue-22692.rs to something more meaningful.
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
Reword resolve errors caused by likely missing crate in dep tree
Reword label and add `help`:
```
error[E0432]: unresolved import `some_novel_crate`
--> f704.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
|
= help: if you wanted to use a crate named `some_novel_crate`, use `cargo add some_novel_crate` to add it to your `Cargo.toml`
```
Fix#133137.
```
error[E0432]: unresolved import `some_novel_crate`
--> file.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
```
On resolve errors where there might be a missing crate, mention `cargo add foo`:
```
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `nope`
--> $DIR/conflicting-impl-with-err.rs:4:11
|
LL | impl From<nope::Thing> for Error {
| ^^^^ use of unresolved module or unlinked crate `nope`
|
= help: if you wanted to use a crate named `nope`, use `cargo add nope` to add it to your `Cargo.toml`
```
Properly note when query stack is being cut off
cc #70953
also, i'm not certain whether we should even limit this at all. i don't see the problem with printing the full query stack, apparently it was limited b/c we used to ICE? but we're already printing the full stack to disk since #108714.
r? oli-obk
This CL makes a number of small changes to dyn compatibility errors:
- "object safety" has been renamed to "dyn-compatibility" throughout
- "Convert to enum" suggestions are no longer generated when there
exists a type-generic impl of the trait or an impl for `dyn OtherTrait`
- Several error messages are reorganized for user readability
Additionally, the dyn compatibility error creation code has been
split out into functions.
cc #132713
cc #133267
- Move `tests/ui/attrs-resolution.rs` to `tests/ui/resolve/`.
- Document test intent.
- Rename test to `non-macro-attrs-accepted.rs` to better reflect test
intent.
- Move `tests/ui/attrs-resolution-errors.rs` to `tests/ui/resolve/`.
- Document test intent.
- Rename test to `attr-macros-positional-rejection.rs` to better reflect
test intent.
When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for.
When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion.
Fix#97734.
fix ICE on type error in promoted
Fixes https://github.com/rust-lang/rust/issues/133968
Ensure that when we turn a type error into a "this promoted failed to evaluate" error, we do record this as something that may happen even in "infallible" promoteds.
When writing a constant name incorrectly in a pattern, the pattern will be identified as a new binding. We look for consts in the current crate, consts that where imported in the current crate and for local `let` bindings in case someone got them confused with `const`s.
```
error: unreachable pattern
--> $DIR/const-with-typo-in-pattern-binding.rs:30:9
|
LL | GOOOD => {}
| ----- matches any value
LL |
LL | _ => {}
| ^ no value can reach this
|
help: you might have meant to pattern match against the value of similarly named constant `GOOD` instead of introducing a new catch-all binding
|
LL | GOOD => {}
| ~~~~
```
Fix#132582.
Use the right span when encountering an enum variant followed by an associated item so we don't lose the associated item in the resulting code.
Do not suggest the thing twice, once as a removal of the associated item and a second time as a typo suggestion.
