Rollup of 6 pull requests
Successful merges:
- #66463 (Point at opaque and closure type definitions in type errors)
- #67501 (Reduce special treatment for zsts)
- #67820 (Parse the syntax described in RFC 2632)
- #67922 (rustc_ast_lowering: misc cleanup & rustc dep reductions)
- #68071 (Extend support of `_` in type parameters)
- #68073 (expect `fn` after `const unsafe` / `const extern`)
Failed merges:
r? @ghost
Extend support of `_` in type parameters
- Account for `impl Trait<_>`.
- Provide a reasonable `Span` for empty `Generics` in `impl`s.
- Account for `fn foo<_>(_: _) {}` to suggest `fn foo<T>(_: T) {}`.
- Fix#67995. Follow up to #67597.
rustc_ast_lowering: misc cleanup & rustc dep reductions
- The first two commits do some code simplification.
- The next three do some file splitting (getting `lib.rs` below the 3kloc tidy lint).
- The remaining commits reduce the number of `rustc::` imports. This works towards making lowering independent of the `rustc` crate.
r? @oli-obk cc @Zoxc
Parse the syntax described in RFC 2632
This adds support for both `impl const Trait for Ty` and `?const Trait` bound syntax from rust-lang/rfcs#2632 to the parser. For now, both modifiers end up in a newly-added `constness` field on `ast::TraitRef`, although this may change once the implementation is fleshed out.
I was planning on using `delay_span_bug` when this syntax is encountered during lowering, but I can't write `should-ice` UI tests. I emit a normal error instead, which causes duplicates when the feature gate is not enabled (see the `.stderr` files for the feature gate tests). Not sure what the desired approach is; Maybe just do nothing when the syntax is encountered with the feature gate is enabled?
@oli-obk I went with `const_trait_impl` and `const_trait_bound_opt_out` for the names of these features. Are these to your liking?
cc #67792#67794
r? @Centril
This means the new syntax will always fail to compile, even when the
feature gate is enabled. These checks will be removed in a later PR
once the implementation is done.
This is used for both the `?const` syntax in bounds as well as the `impl
const Trait` syntax. I also considered handling these separately by
adding a variant of `TraitBoundModifier` and a field to
`ItemKind::Impl`, but this approach was less intrusive.
