Report that opaque types are not allowed in impls even in the presence of other errors
fixes #96569
before this PR those useful errors were hidden because either `unused parameter` or `only traits defined in the current crate can be implemented for arbitrary types` got emitted first.
Mitigate impact of subtle invalid call suggestion logic
There's some subtle interaction between inferred expressions being
passed as an argument to fn calls with fewer than expected arguments. To
avoid the ICE, I'm changing indexing operations with `.get(idx)`, but
the underlying logic still needs to be audited as it was written with
the assumption that `final_arg_types` and `provided_args` have the right
length.
Address #96638.
Use source callsite in check_argument_types suggestion
This makes the "remove extra arguement" suggestion valid when the function argument is a macro.
Additionally, this may fix#96225, but the only way I can reproduce that issue is using the playground, so we will need to wait until after this is merged to ensure it's fixed.
There's some subtle interaction between inferred expressions being
passed as an argument to fn calls with fewer than expected arguments. To
avoid the ICE, I'm changing indexing operations with `.get(idx)`, but
the underlying logic still needs to be audited as it was written with
the assumption that `final_arg_types` and `provided_args` have the right
length.
Address 96638.
Only crate root def-ids don't have a parent, and in majority of cases the argument of `DefIdTree::parent` cannot be a crate root.
So we now panic by default in `parent` and introduce a new non-panicing function `opt_parent` for cases where the argument can be a crate root.
Same applies to `local_parent`/`opt_local_parent`.
Enforce Copy bounds for repeat elements while considering lifetimes
fixes https://github.com/rust-lang/rust/issues/95477
this is a breaking change in order to fix a soundness bug.
Before this PR we only checked whether the repeat element type had an `impl Copy`, but not whether that impl also had the appropriate lifetimes. E.g. if the impl was for `YourType<'static>` and not a general `'a`, then copying any type other than a `'static` one should have been rejected, but wasn't.
r? `@lcnr`
macros: subdiagnostic derive
Add a new macro, `#[derive(SessionSubdiagnostic)]`, which can be applied to structs that represent subdiagnostics, such as labels, notes, helps or suggestions.
`#[derive(SessionSubdiagnostic)]` can be used with the existing `#[derive(SessionDiagnostic)]`. All diagnostics implemented using either derive are translatable, and this new derive should make it easier to port existing diagnostics to using these derives.
For example, consider the following subdiagnostic types...
```rust
#[derive(SessionSubdiagnostic)]
pub enum ExpectedIdentifierLabel<'tcx> {
#[label(slug = "parser-expected-identifier")]
WithoutFound {
#[primary_span]
span: Span,
}
#[label(slug = "parser-expected-identifier-found")]
WithFound {
#[primary_span]
span: Span,
found: String,
}
}
#[derive(SessionSubdiagnostic)]
#[suggestion_verbose(slug = "parser-raw-identifier")]
pub struct RawIdentifierSuggestion<'tcx> {
#[primary_span]
span: Span,
#[applicability]
applicability: Applicability,
ident: Ident,
}
```
...and the corresponding Fluent messages:
```fluent
parser-expected-identifier = expected identifier
parser-expected-identifier-found = expected identifier, found {$found}
parser-raw-identifier = escape `{$ident}` to use it as an identifier
```
These can be emitted using the new `subdiagnostic` function on `Diagnostic`...
```rust
diag.subdiagnostic(ExpectedIdentifierLabel::WithoutFound { span });
diag.subdiagnostic(RawIdentifierSuggestion { span, applicability, ident });
```
...or as part of a larger `#[derive(SessionDiagnostic)]`:
```rust
#[derive(SessionDiagnostic)]
#[error(slug = "parser-expected-identifier")]
pub struct ExpectedIdentifier {
#[primary_span]
span: Span,
token_descr: String,
#[subdiagnostic]
label: ExpectedIdentifierLabel,
#[subdiagnostic]
raw_identifier_suggestion: Option<RawIdentifierSuggestion>,
}
```
```rust
sess.emit_err(ExpectedIdentifier { ... });
```
r? `@oli-obk`
cc `@pvdrz`
Add a new derive, `#[derive(SessionSubdiagnostic)]`, which enables
deriving structs for labels, notes, helps and suggestions.
Signed-off-by: David Wood <david.wood@huawei.com>
make `fn() -> _ { .. }` suggestion MachineApplicable
This might not be valid, but it would be nice to promote this to `MachineApplicable` so people can use rustfix here.
Also de65fcf009d07019689cfad7f327667e390a325d is to [restore the suggestion for `issue-77179.rs`](de65fcf009 (diff-12e43fb5d6d12ec7cb5c6b48204a18d113cf5de0e12eb71a358b639bd9aadaf0R8)). (though in this case, the code in that issue still doesn't compile, so it's not marked with rustfix).
Fix erased region escaping into wfcheck due to #95395
We can just use `liberate_late_bound_regions` instead of `erase_late_bound_regions`... This gives us `ReEarlyBound` instead of `ReErased`, the former being something typeck actually knows how to deal with...
Fixes#96381
Side-note: We only actually get far enough in the compiler pipeline to cause this ICE when we're invoking rustdoc. We actually abort rustc right before wfcheck because of the error that we emit (having `_` in the type signature). Why does rustdoc keep going even though we raise an error?
Cleanup `report_method_error` a bit
1. Remove an unnecessary indentation level
2. Split out a couple of large functions from this humongo function body
Suggest calling method on nested field when struct is missing method
Similar to the suggestion to change `x.field` to `x.nested.field`, implement a similar suggestion for when `x.method()` should be replaced with `x.nested.method()`.
Fix incorrect suggestion for trait bounds involving binary operators
This PR fixes#93927, #92347, #93744 by replacing the bespoke trait-suggestion logic in `op.rs` with a more common code path.
The downside is that this fix causes some suggestions to not include an `Output=` type, reducing their usefulness.
Note that this causes one case in the `missing-bounds.rs` test to fail rustfix. So I would need to move that code into a separate non-fix test if this PR is otherwise acceptable.
