Use `default_field_values` for `rustc_errors::Context`, `rustc_session::config::NextSolverConfig` and `rustc_session::config::ErrorOutputType`
Wanted to see where `#![feature(default_field_values)]` could be used in the codebase. These three seemed like no-brainers. There are a bunch of more places where we could remove manual `Default` impls, but they `derive` other traits that rely on `syn`, which [doesn't yet support `default_field_values`](https://github.com/dtolnay/syn/issues/1774).
Remove `MaybeForgetReturn` suggestion
#115196 implemented a suggestion to add a missing `return` when there is an ambiguity error, when that ambiguity error could be constrained by the return type of the function.
I initially reviewed it and thought it could be useful; however, looking back at that code now, I feel like it's a bit too much of a hack to be worth keeping around in typeck, especially given how rare it's expected to fire in practice. This is especially true because it depends on `StashKey::MaybeForgetReturn`, which is only stashed when we have *Sized* obligation ambiguity errors. Let's remove it for now.
I'd like to note that it's basically impossible to get this suggestion to apply in its current state except for what I'd consider somewhat artificial examples, involving no generic trait bounds. For example, it's not triggered for:
```rust
struct W<T>(T);
fn bar<T: Default>() -> W<T> { todo!() }
fn foo() -> W<i32> {
if true {
bar();
}
W(0)
}
```
Nor is it triggered for:
```
fn foo() -> i32 {
if true {
Default::default();
}
0
}
```
It's basically only triggered iff there's only one ambiguity error on the type, which is `Sized`.
Generally, suggesting something that affects control flow is a pretty dramatic suggestion; therefore, both the accuracy and precision of this diagnostic should be pretty high.
One other, somewhat unrelated observation is that this might be using stashed diagnostics incorrectly (or at least unnecessarily). Stashed diagnostics are used when error detection is fragmented over several major stages of the compiler, like a parse or resolver error which later can be recovered in typeck. However, this one is a bit different since it is fully handled within typeck -- perhaps that suggests that if this were to be reimplemented, it wouldn't need to be so complicated of an implementation.
Provide a new function `listify`, meant to be used in cases similar to `pluralize!`. When you have a slice of arbitrary elements that need to be presented to the user, `listify` allows you to turn that into a list of comma separated strings.
This reduces a lot of redundant logic that happens often in diagnostics.
suppress field expr with generics error message if it's a method
Don't emit "field expressions may not have generic arguments" if it's a method call without `()`
r? estebank
Fixes#67680
Is this the best way to go? It's by far the simplest I could come up with.
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.
Fix clippy lint suggestion incorrectly treated as `span_help`.
Matthias Krüger