typeck: suggest use of match_default_bindings feature
Fixes#45383.
Updates #42640.
r? @nikomatsakis
cc @tschottdorf
This needs a UI test, but thought I'd get some early feedback.
Improve display of error E0308
Ref. Forgetting to call a variant constructor causes a confusing error message #35241.
This PR modifies [`note_type_err`](b7041bfab3/src/librustc/infer/error_reporting/mod.rs (L669-L674)) to display a `help` message when a `TyFnPtr` or `TyFnDef` are found and the return type, of the function or function pointer, is the same as the type that is expected.
The output of compiling
```rust
struct Foo(u32);
fn test() -> Foo { Foo }
fn main() {}
```
is now
```bash
$ rustc src/test/ui/issue-35241.rs
error[E0308]: mismatched types
--> src/test/ui/issue-35241.rs:13:20
|
13 | fn test() -> Foo { Foo }
| --- ^^^ expected struct `Foo`, found fn item
| |
| expected `Foo` because of return type
|
= help: did you mean `Foo { /* fields */ }`?
= note: expected type `Foo`
found type `fn(u32) -> Foo {Foo::{{constructor}}}`
error: aborting due to previous error
```
Suggest renaming import if names clash
Closes https://github.com/rust-lang/rust/issues/32354.
The output for the example in the issue looks like this:
```
~/p/local-rust-dev-testing ❯❯❯ cargo +local-s1 build
Compiling local-rust-dev-testing v0.1.0 (file:///home/cldfire/programming_projects/local-rust-dev-testing)
error[E0252]: the name `ConstructorExtension` is defined multiple times
--> src/main.rs:49:5
|
48 | use extension1::ConstructorExtension;
| -------------------------------- previous import of the trait `ConstructorExtension` here
49 | use extension2::ConstructorExtension;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `ConstructorExtension` reimported here
|
= note: `ConstructorExtension` must be defined only once in the type namespace of this module
help: You can use `as` to change the binding name of the import
|
49 | use extension2::ConstructorExtension as OtherConstructorExtension;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
```
This is my first PR that touches the compiler in any way, so if there's something else I need to do here (e.g. add a test), please let me know :).
This multiline string literal was missing a backslash, leaving an awkward
newline and 35 spaces in the middle of the message.
But while we're here, the existing message seems kind of long in comparison to
similar notes: to cut it down, we excise the mentions of doc comments, which
seems sensible because we know that this erroneous attribute is not a doc
comment (notice the `is_sugared_doc: false` at the end of the function; if it
had been a doc comment, that error would get set in the `token::DocComment`
match branch of `parse_outer_attributes`).
Fix duplicate display of error E0502
Ref. Repeated "mutable/immutable borrow" error messages #42106.
This PR modifies the return type of [`report_error_if_loan_conflicts_with_restriction`](0f0f5db465/src/librustc_borrowck/borrowck/check_loans.rs (L398-L403)) so the result can be checked in [`report_error_if_loans_conflict`](0f0f5db465/src/librustc_borrowck/borrowck/check_loans.rs (L377-L396)). This is done to prevent displaying a duplicate of the error message E0502 which is referenced in #42106.
The output of compiling:
```rust
fn do_something<T>(collection: &mut Vec<T>) {
let _a = &collection;
collection.swap(1, 2);
}
fn main() {}
```
is now
```bash
$ rustc src/test/compile-fail/issue-42106.rs
error[E0502]: cannot borrow `*collection` as mutable because `collection` is also borrowed as immutable
--> src/test/compile-fail/issue-42106.rs:13:5
|
12 | let _a = &collection;
| ---------- immutable borrow occurs here
13 | collection.swap(1, 2);
| ^^^^^^^^^^ mutable borrow occurs here
14 | }
| - immutable borrow ends here
error: aborting due to 2 previous errors
```
r? @estebank
Improve diagnostics when list of tokens has incorrect separators
Make `parse_seq_to_before_tokens` more resilient to error conditions. Where possible it is better if it can consume up to the final bracket before returning. This change improves the diagnostics in a couple of situations:
```
struct S(pub () ()); // omitted separator
use std::{foo. bar}; // used a similar but wrong separator
```
Fixes#44339
r? @petrochenkov
Don't emit the same compiler diagnostic twice.
This PR makes the compiler filter out diagnostic messages that have already been emitted during the same compilation session.
don't issue "expected statement after outer attr." after inner attr.
While an inner attribute here is in fact erroneous, that error ("inner
attribute is not permitted in this context") successfully gets set earlier;
this further admonition is nonsensical.
Resolves#45296.
rustc: Remove `used_mut_nodes` from `TyCtxt`
This updates the borrowck query to return a result, and this result is then used
to incrementally check for unused mutable nodes given sets of all the used
mutable nodes.
Closes#42384
While an inner attribute here is in fact erroneous, that error ("inner
attribute is not permitted in this context") successfully gets set earlier;
this further admonition is nonsensical.
Resolves#45296.
Provide the full span of method calls to `check_argument_types`
... so that it includes the span of the passed arguments, not just the name of the called method.
Fixes#44760.
This updates the borrowck query to return a result, and this result is then used
to incrementally check for unused mutable nodes given sets of all the used
mutable nodes.
Closes#42384
Point at immutable outer variable
When attempting to mutate an immutable outer variable from a closure,
point at the outer variable and suggest making it mutable.
Fix#41790.
Better error message for comma after base struct
#41834
This adds a better error for commas after the base struct:
```
let foo = Foo {
one: 111,
..Foo::default(), // This comma is a syntax error
};
```
The current error is a generic `expected one of ...` which isn't beginner-friendly. My error looks like this:
```
error: cannot use a comma after the base struct
--> tmp/example.rs:26:9
|
26 | ..Foo::default(),
| ^^^^^^^^^^^^^^^^- help: remove this comma
|
= note: the base struct expansion must always be the last field
```
I even added a note for people who don't know why this isn't allowed.
