More explicit diagnostic when using a `vec![]` in a pattern
```
error: unexpected `(` after qualified path
--> $DIR/vec-macro-in-pattern.rs:3:14
|
LL | Some(vec![x]) => (),
| ^^^^^^^
| |
| unexpected `(` after qualified path
| in this macro invocation
| use a slice pattern here instead
|
= help: for more information, see https://doc.rust-lang.org/edition-guide/rust-2018/slice-patterns.html
= note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
```
Fix#61933.
```
error: unexpected `(` after qualified path
--> $DIR/vec-macro-in-pattern.rs:3:14
|
LL | Some(vec![x]) => (),
| ^^^^^^^
| |
| unexpected `(` after qualified path
| in this macro invocation
| use a slice pattern here instead
|
= help: for more information, see https://doc.rust-lang.org/edition-guide/rust-2018/slice-patterns.html
= note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
```
Stop bare trait lint applying to macro call sites
Fixes#61963. Apologies for the delay with in fixing this. If anyone has a better idea how to detect this macro call site case, I'd be happy to fix this in a more robust, less hacky way.
r? @estebank
Suggest trait bound on type parameter when it is unconstrained
Given
```
trait Foo { fn method(&self) {} }
fn call_method<T>(x: &T) {
x.method()
}
```
suggest constraining `T` with `Foo`.
Fix#21673, fix#41030.
This commit adds a reproduction of the error reported in servo which
demonstrates the current, incorrect behaviour.
Co-authored-by: Rémy Rakić <remy.rakic@gmail.com>
Normally `#![feature(...)]` shouldn't change behavior, but custom attributes in particular are in the process of retirement, and we should not produce a message telling to enable them.
It also helps with unifying diagnostics for unresolved macros.
As per issue #54985 removes the not useful suggestion to remove asterisk in
move errors. Includes minor changes to tests in the `ui` suite to account
for the removed suggestion.
Warn on bare_trait_objects by default
The `bare_trait_objects` lint is set to `warn` by default.
Most ui tests have been updated to use `dyn` to avoid creating noise in stderr files.
r? @Centril
cc #54910
This commit stops `unused_extern_crates` lints from occuring on `extern
crate` statements that alias the crate as the suggestion to change to a
`use` statement would result in the aliased name no longer being added
to the prelude, thereby causing compilation errors if other imports
expected this to be the case.