Suggest defining type parameter when appropriate
```
error[E0412]: cannot find type `T` in this scope
--> file.rs:3:12
|
3 | impl Trait<T> for Struct {}
| - ^ not found in this scope
| |
| help: you might be missing a type parameter: `<T>`
```
Fix#64298.
```
error[E0412]: cannot find type `T` in this scope
--> file.rs:3:12
|
3 | impl Trait<T> for Struct {}
| - ^ not found in this scope
| |
| help: you might be missing a type parameter: `<T>`
```
Fix#64298.
Rollup of 6 pull requests
Successful merges:
- #67956 (Detail transitive containment in E0588 diagnostic)
- #68153 (resolve: Point at the private item definitions in privacy errors)
- #68195 (Account for common `impl Trait`/`dyn Trait` return type errors)
- #68288 (Fix some of the rustfmt fallout in Miri)
- #68292 (don't clone types that are copy)
- #68301 (Don't propagate __RUST_TEST_INVOKE to subprocess)
Failed merges:
r? @ghost
Account for common `impl Trait`/`dyn Trait` return type errors
- When all return paths have the same type, suggest `impl Trait`.
- When all return paths implement the expected `trait`, suggest `Box<dyn Trait>` and mention using an `enum`.
- When multiple different types are returned and `impl Trait` is expected, extend the explanation.
- When return type is `impl Trait` and the return paths do not implement `Trait`, point at the returned values.
- Split `src/librustc/traits/error_reporting.rs` into multiple files to keep size under control.
Fix#68110, cc #66523.
Clean up some diagnostics by making them more consistent
In general:
- Diagnostic should start with a lowercase letter.
- Diagnostics should not end with a full stop.
- Ellipses contain three dots.
- Backticks should encode Rust code.
I also reworded a couple of messages to make them read more clearly.
It might be sensible to create a style guide for diagnostics, so these informal conventions are written down somewhere, after which we could audit the existing diagnostics.
r? @Centril
tweak wording of mismatched delimiter errors
This PR improves the wording of the "incorrect delimiter" error messages. Here's a quick rationale:
- *"un-closed" -> "unclosed"*: "unclosed" is valid English, so there's no need to hyphenate the prefix. This should be pretty uncontroversial, I think.
- *"close delimiter" -> "closing delimiter"*: In my anecdotal experience, I've always heard "closing delimiter" or "closing parenthesis". In addition, the codebase already uses this terminology in comments and function names more than "close delimiter", which could indicate that it's more intuitive.
- "incorrect delimiter" -> "mismatched delimiter": "Incorrect delimiter" is vague; why is it incorrect? "mismatched" clearly indicates why the delimiter is causing the error.
r? @estebank
- Use the span of the predicate
- Use the def's description instead of "struct/enum" (notably incorrect
for unions)
- Align formatting with other error messages
