This just applies the suggested fixes from the compatibility warnings,
leaving any that are in practice spurious in. This is primarily intended to
provide a starting point to identify possible fixes to the migrations (e.g., by
avoiding spurious warnings).
A secondary commit cleans these up where they are false positives (as is true in
many of the cases).
Gather module items after lowering.
This avoids having a non-local analysis inside lowering.
By implementing `hir_module_items` using a visitor, we make sure that iterations and visitors are consistent.
Suggest better place to add call parentheses for method expressions wrapped in parentheses
I wanted to improve the suggestion a bit to both remove the wrapping parentheses **and** add call parentheses by both calling `suggest_method_call` and using `multipart_suggestion`. But I very quickly ran into a problem where multiple overlapping machine applicable suggestions cannot be properly applied together. So I applied the suggestion from the issue and only added the call parentheses directly after the expression.
Fixes: https://github.com/rust-lang/rust/issues/89044
Suggest replacing an inexisting field for an unmentioned field
Fix#87938
This PR adds a suggestion to replace an inexisting field for an
unmentioned field. Given the following code:
```rust
enum Foo {
Bar { alpha: u8, bravo: u8, charlie: u8 },
}
fn foo(foo: Foo) {
match foo {
Foo::Bar {
alpha,
beta, // `bravo` miswritten as `beta` here.
charlie,
} => todo!(),
}
}
```
the compiler now emits the error messages below.
```text
error[E0026]: variant `Foo::Bar` does not have a field named `beta`
--> src/lib.rs:9:13
|
9 | beta, // `bravo` miswritten as `beta` here.
| ^^^^
| |
| variant `Foo::Bar` does not have this field
| help: `Foo::Bar` has a field named `bravo`: `bravo`
```
Note that this suggestion is available iff the number of inexisting
fields and unmentioned fields are both 1.
Propagate coercion cause into `try_coerce`
Currently, `coerce_inner` discards its `ObligationCause`
when calling `try_coerce`. This interfers with other
diagnostc improvements I'm working on, since we will lose
the original span by the time the actual coercion occurs.
Additionally, we now use the span of the trailing expression
(rather than the span of the entire function) when performing
a coercion in `check_return_expr`. This currently has no visible
effect on any of the unit tests, but will unblock future
diagnostic improvements.
Fix handling of `hir::GenericArg::Infer` in `wrong_number_of_generic_args.rs`
Fixes#87563. More precisely, I have fixed the "index out of bounds" error, which is what #87563 is about. The example given there still ICEs due to running into this `todo!()`, but I'd say that this is a separate issue:
c3c0f80d60/compiler/rustc_typeck/src/astconv/mod.rs (L460-L463)
Do not issue E0071 if a type error has already been reported
Fixes#88844. A suggested fix is already included in the error message for E0412, so with my changes, E0071 is simply not emitted anymore if the type in question is a "type error". This makes sense, I think, because we cannot confidently state that something is "not a struct" if we couldn't resolve it properly; and it's unnecessary to pollute the output with this additional error message, as it is a direct consequence of the former error.
I have also addressed the issue mentioned in https://github.com/rust-lang/rust/issues/88844#issuecomment-917324856 by changing the fixed example in the documentation to more closely match the erroneous code example.
Currently, `coerce_inner` discards its `ObligationCause`
when calling `try_coerce`. This interfers with other
diagnostc improvements I'm working on, since we will lose
the original span by the time the actual coercion occurs.
Additionally, we now use the span of the trailing expression
(rather than the span of the entire function) when performing
a coercion in `check_return_expr`. This currently has no visible
effect on any of the unit tests, but will unblock future
diagnostic improvements.
When evaluating an `ExprKind::Call`, we first have to `check_expr` on it's
callee. When this one is a `ExprKind::Path`, we had to evaluate the bounds
introduced for its arguments, but by the time we evaluated them we no
longer had access to the argument spans. Now we special case this so
that we can point at the right place on unsatisfied bounds. This also
allows the E0277 deduplication to kick in correctly, so we now emit
fewer errors.
Move the information about pointing at the call argument expression in
an unmet obligation span from the `FulfillmentError` to a new
`ObligationCauseCode`.
Add non_exhaustive_omitted_patterns lint related to rfc-2008-non_exhaustive
Fixes: #84332
This PR adds `non_exhaustive_omitted_patterns`, an allow by default lint that is triggered when a `non_exhaustive` type is missing explicit patterns. The warning or deny attribute can be put above the wildcard `_` pattern on enums or on the expression for enums or structs. The lint is capable of warning about multiple types within the same pattern. This lint will not be triggered for `if let ..` patterns.
```rust
// crate A
#[non_exhaustive]
pub struct Foo {
a: u8,
b: usize,
}
#[non_exhaustive]
pub enum Bar {
A(Foo),
B,
}
// crate B
#[deny(non_exhaustive_omitted_patterns)] // here
match Bar::B {
Bar::B => {}
#[deny(non_exhaustive_omitted_patterns)] // or here
_ => {}
}
#[warn(non_exhaustive_omitted_patterns)] // only here
let Foo { a, .. } = Foo::default();
#[deny(non_exhaustive_omitted_patterns)]
match Bar::B {
// triggers for Bar::B, and Foo.b
Bar::A(Foo { a, .. }) => {}
// if the attribute was here only Bar::B would cause a warning
_ => {}
}
```
Add linting on non_exhaustive structs and enum variants
Add ui tests for non_exhaustive reachable lint
Rename to non_exhaustive_omitted_patterns and avoid triggering on if let
Use smaller spans for some structured suggestions
Use more accurate suggestion spans for
* argument parse error
* fully qualified path
* missing code block type
* numeric casts
This PR adds a suggestion to replace an inexisting field for an
unmentioned field. Given the following code:
```rust
enum Foo {
Bar { alpha: u8, bravo: u8, charlie: u8 },
}
fn foo(foo: Foo) {
match foo {
Foo::Bar {
alpha,
beta, // `bravo` miswritten as `beta` here.
charlie,
} => todo!(),
}
}
```
the compiler now emits the error messages below.
```text
error[E0026]: variant `Foo::Bar` does not have a field named `beta`
--> src/lib.rs:9:13
|
9 | beta, // `bravo` miswritten as `beta` here.
| ^^^^
| |
| variant `Foo::Bar` does not have this field
| help: `Foo::Bar` has a field named `bravo`: `bravo`
```
Note that this suggestion is available iff the number of inexisting
fields and unmentioned fields are both 1.
Add -Z panic-in-drop={unwind,abort} command-line option
This PR changes `Drop` to abort if an unwinding panic attempts to escape it, making the process abort instead. This has several benefits:
- The current behavior when unwinding out of `Drop` is very unintuitive and easy to miss: unwinding continues, but the remaining drops in scope are simply leaked.
- A lot of unsafe code doesn't expect drops to unwind, which can lead to unsoundness:
- https://github.com/servo/rust-smallvec/issues/14
- https://github.com/bluss/arrayvec/issues/3
- There is a code size and compilation time cost to this: LLVM needs to generate extra landing pads out of all calls in a drop implementation. This can compound when functions are inlined since unwinding will then continue on to process drops in the callee, which can itself unwind, etc.
- Initial measurements show a 3% size reduction and up to 10% compilation time reduction on some crates (`syn`).
One thing to note about `-Z panic-in-drop=abort` is that *all* crates must be built with this option for it to be sound since it makes the compiler assume that dropping `Box<dyn Any>` will never unwind.
cc https://github.com/rust-lang/lang-team/issues/97
Encode spans relative to the enclosing item
The aim of this PR is to avoid recomputing queries when code is moved without modification.
MCP at https://github.com/rust-lang/compiler-team/issues/443
This is achieved by :
1. storing the HIR owner LocalDefId information inside the span;
2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache;
3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation.
Since all client code uses `Span`, step 3 ensures that all manipulations
of span byte positions actually create the dependency edge between
the caller and the `source_span(LocalDefId)`.
This query return the actual absolute span of the parent item.
As a consequence, any source code motion that changes the absolute byte position of a node will either:
- modify the distance to the parent's beginning, so change the relative span's hash;
- dirty `source_span`, and trigger the incremental recomputation of all code that
depends on the span's absolute byte position.
With this scheme, I believe the dependency tracking to be accurate.
For the moment, the spans are marked during lowering.
I'd rather do this during def-collection,
but the AST MutVisitor is not practical enough just yet.
The only difference is that we attach macro-expanded spans
to their expansion point instead of the macro itself.
Fix non-capturing closure return type coercion
Fixes#88097. For the example given there:
```rust
fn peculiar() -> impl Fn(u8) -> u8 {
return |x| x + 1
}
```
which incorrectly reports an error, I noticed something weird in the debug log:
```
DEBUG rustc_typeck::check::coercion coercion::try_find_coercion_lub([closure@test.rs:2:12: 2:21], [closure@test.rs:2:12: 2:21], exprs=1 exprs)
```
Apparently, `try_find_coercion_lub()` thinks that the LUB for two closure types always has to be a function pointer (which explains the `expected closure, found fn pointer` error in #88097). There is one corner case where that isn't true, though — namely, when the two closure types are equal, in which case the trivial LUB is the type itself. This PR fixes this by inserting an explicit check for type equality in `try_find_coercion_lub()`.
Split rustc_mir
The `rustc_mir` crate is the second largest in the compiler.
This PR splits it up into 5 crates:
- rustc_borrowck;
- rustc_const_eval;
- rustc_mir_dataflow;
- rustc_mir_transform;
- rustc_monomorphize.
Suggest deriving traits if possible
This only applies to builtin derives as I don't think there is a
clean way to get the available derives in typeck.
Closes#85851
Remove `hir::GenericBound::Unsized`
Rather than "moving" the `?Sized` bounds to the param bounds, just also check where clauses in `astconv`. I also did some related cleanup here, but that's not strictly neccesary. Also going to do a perf run here.
r? `@estebank`
