Rust 2015 type `dyn + dyn` wrongly rejected by the parser due to "helpful" diagnostic

[fmease]

In Rust 2015, dyn is only a contextual keyword. It is only meant to be active if it appears in a type context and is followed by a token in the following set: {PathIdentSegment, LIFETIME_OR_LABEL, for, (, ?} as dictated by can_begin_dyn_bound_in_edition_2015 (cc rust-lang/reference#2257) (side note: RFC 2113 doesn't actually define the rules).

Despite that fact, since 1.54 rustc rejects the following Rust 2015 program:

#[cfg(false)]
type X = dyn + dyn;

error: invalid `dyn` keyword
 --> src/lib.rs:2:16
  |
2 | type X = dyn + dyn;
  |                ^^^
  |
  = help: `dyn` is only needed at the start of a trait `+`-separated list
help: remove this keyword
  |
2 - type X = dyn + dyn;
2 + type X = dyn + ;
  |

error: expected identifier, found `;`
 --> src/lib.rs:2:19
  |
2 | type X = dyn + dyn;
  |                   ^ expected identifier

More concretely, rustc erroneously rejects this code since PR #84896 which only meant to improve diagnostics, not alter the stable grammar of Rust.

Note that dyn + dyn can be semantically well-formed, too (assuming this parser bug has been fixed). Consider the following contrived Rust 2015 code:

use std::marker::Sync as dyn;
type Y = dyn + dyn;

[fmease]

The problematic part of the code is:

rust/compiler/rustc_parse/src/parser/ty.rs

Line 1095 in 83adf7e

if self.token.is_keyword(kw::Dyn) {

.

I believe it to be acceptable if the PR fixing this won't get lang-FCP'ed, adding relnotes Marks issues that should be documented in the release notes of the next release. and updating the corresponding relnotes-tracking-issue Marks issues tracking what text to put in release notes. issue to make it a Compatibility Note should be more than sufficient.

[fmease]

Side note: It's kinda odd and footgunny that is_keyword doesn't consult the edition of the span of the identifier. I wonder how many other bugs this enables...

It should probably be called is_ident_named instead since that what it actually checks (and it's also used for edition-insensitive contextual keywords).

[fmease]

Re. E-easy: You just need to add && self.token.span.at_least_rust_2018() following the is_keyword check, add a test somewhere in tests/ui/parser/ (ideally into a existing test file that already exercise dyn-as-a-normal-identifier) and label the PR with relnotes Marks issues that should be documented in the release notes of the next release. using @rustbot label.

[Willi0728]

@rustbot claim