Improve invalid_value lint message
The lint now explains which type is involved and why it cannot be initialized this way. It also points at the innermost struct/enum field that has an offending type, if any.
See https://github.com/erlepereira/x11-rs/issues/99#issuecomment-520311911 for how this helps in some real-world code hitting this lint.
resolve: Remove remaining special cases from built-in macros
Edition and definition sites of the macros are now also taken from the `#[rustc_builtin_macro]` definitions in `libcore`.
---
The edition switch may be a breaking change for `Rustc{Encodable,Decodable}` derives if they are used in combination with the unstable crate `serialize` from sysroot like this
```rust
extern crate serialize;
use serialize as rustc_serialize;
#[derive(RustcEncodable)]
struct S;
```
(see the updated `ui-fulldeps` tests).
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.
Cleanup some surrounding code.
Support resolution of intra doc links in unnamed block scopes.
(Paths from rustdoc now use early resolution and no longer need results of late resolution like all the built ribs.)
Fix one test hitting file path limits on Windows.
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.
Sort the fat LTO modules to produce deterministic output.
Some projects that use LTO for their release builds are not reproducible. We can fix this by sorting the fat LTO modules before using them.
It might also be useful to do this for thin LTO, but I couldn't get that to work to test it so I didn't do it.
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.
Tweak mismatched types error
- Change expected/found for type mismatches in `break`
- Be more accurate when talking about diverging match arms
- Tweak wording of function without a return value
- Suggest calling bare functions when their return value can be coerced to the expected type
- Give more parsing errors when encountering `foo(_, _, _)`
Fix#51767, fix#62677, fix#63136, cc #37384, cc #35241, cc #51669.
```
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)
```
