León Orell Valerian Liehr

Technically speaking not specific to `const_trait_impl` but it's CTI that now suffers the consequences.

> I think that the right strategy for qualifier parsing is to detect that there's *any* qualifier and then collect qualifiers in a loop, regardless of order, and then check...

Tho, I guess the approach is still possible even tho it needs to be a bit more involved. I'm thinking of sth. like ```rs fn parse_item_modifier_candidates(&mut self) -> PResult; enum...

This could be very easily expressed using backtracking I believe (contrary to the look aheads we need to do rn) but as you know we're not meant to do that...

Oh gawd, while the context-sensitive keyword `auto` is treated as a qualifier where possible, `safe` is super inflexible but I think we can be a lot more liberal and treat...

More issues in the vicinity (I'm assuming Rust 2024 here): * (expr) stmt `async gen || {};` doesn't parse even tho `_ = async gen || {};` and `for async...

In PR #147864, we added another special case (hack) to the "fn frontmatter" check to support `const unsafe trait Trait {}` (etc.) from the issue description. Since PR #148434, we...

@rustbot concern lang This proposal affects the language and as such it is first and foremost a T-lang matter, not a T-compiler one. This should be refiled as a request...

> I did not add the "create a similar PR" text in the rollup PR description as I'm not sure it's used I've used it very often. It's super helpful...

@dingxiangfei2009 Please don't force-push in this repo, that's heavily discouraged. From the README.md: > Specifically, do not squash or rebase commits after they are visible on the pull request.