This commit changes the behavior of Formatter::debug_struct,
debug_tuple, debug_list, debug_set, and debug_map to render trailing
commas in {:#?} mode, which is the dominant style in modern Rust code.
Before:
Language {
name: "Rust",
trailing_commas: false
}
After:
Language {
name: "Rust",
trailing_commas: true,
}
resolve: collect trait aliases along with traits
It seems trait aliases weren't being collected as `TraitCandidates` in resolve, this should change that. (I can't compile the full compiler locally, so relying on CI...)
Fixes https://github.com/rust-lang/rust/issues/56485
r? @alexreg
async fn now lowers directly to an existential type declaration
rather than reusing the `impl Trait` return type lowering.
As part of this, it lowers all argument-position elided lifetimes
using the in-band-lifetimes machinery, creating fresh parameter
names for each of them, using each lifetime parameter as a generic
argument to the generated existential type.
This doesn't currently successfully allow multiple
argument-position elided lifetimes since `existential type`
doesn't yet support multiple lifetimes where neither outlive
the other. This requires a separate fix.
Fallback to `static_impl_trait` for nice error message by peeking at the
return type and the lifetime type. Point at the return type instead of
the return expr/stmt in NLL mode.
skip dyn keyword lint under macros
This PR is following my own intuition that `rustfix` should never inject bugs into working code (even if that comes at the expense of it failing to fix things that will become bugs).
Fix#56327
This commit removes the check that disallows the `#[non_exhaustive]`
attribute from being placed on enum variants and removes the associated
tests.
Further, this commit lowers the visibility of enum variant constructors
when the variant is marked as non-exhaustive.
Review feedback asked for the test to be generalized to include macros
2.0; that generalization is dyn-2015-idents-in-decl-macros-unlinted.rs
As a drive-by, I also decided to revise the test to make it clear
*why* we cannot generally lint these cases. (I already had similar
demonstrations in dyn-2015-edition-keyword-ident-lint.rs, but it does
not hurt to try to emphasize matters.)
I also added some commentary on the cases where we could choose to
make the lint smarter, namely the situations where a macro is
*definitely* using `dyn` as an identifier (because it is using it as a
path component).
Back-story: After reflection this morning, I realized that the
previous form of this test would allow the macro invocation to treat
the `dyn` input as a raw-identifier rather than a keyword, and since
the input was discarded by that version of the macro, the test would
pass despite the detail that the input `dyn` should not have been
parsed as a raw-identifier.
This revision fixes that oversight, by actually *using* the macro
input to construct a `Box<dyn Trait>` type.
Do not complain about unmentioned fields in recovered patterns
When the parser has to recover from malformed code in a pattern, do not
complain about missing fields.
Fix#59145.
When two multiline span labels point at the same span, we special
case the output to avoid weird behavior:
```
foo(
_____^
|_____|
|| bar,
|| );
|| ^
||______|
|______foo
baz
```
instead showing
```
foo(
_____^
| bar,
| );
| ^
| |
|______foo
baz
```
