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.
- 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.
Export public scalar statics in wasm
Fixes#67453
I am not sure which export level statics should get when exporting them in wasm. This small change fixes the issue that I had, but this might not be the correct way to implement this.
Simplify into_key_slice_mut
Remove a rare and tiny but superfluous run-time check from into_key_slice_mut.
In #67459, I wrote that "`get_mut` [...] does visit `into_key_slice_mut`" and that was wrong. No function that operates on a map that (still) has a shared root ever dives into `into_key_slice_mut`. So it's more clear to remove the (previously existing, and always incomplete) code it has for dealing with shared roots, as well as a petty performance improvement for those using exotically aligned key types.
~~Also, some testing of the `range` function initially added to #67686 but hardly related.~~
r? @RalfJung
Add HashSet::get_or_insert_owned
This is an extension for tracking issue #60896. The more-general `get_or_insert_with` has potential for misuse, so we might remove it, but I think `get_or_insert_owned` covers most use cases.
Do not deduplicate diagnostics in UI tests
Error reporting infrastructure deduplicates identical diagnostics with identical spans.
While it's preferable to do this in "release"/"user-facing" mode, it sometimes brings [confusion](https://github.com/rust-lang/rust/pull/50682#issuecomment-390949878) and hides details that may be important during development.
Do we run some passes multiple times when we could do it once?
How many times we run them exactly? Can this number be large? Can the multiplied error construction be expensive? Can speculative checks be made cheaper if they don't report errors?
*Relying* on this mechanism to deduplicate some specific error never looks like a proper solution to me personally.
In this PR I attempt to disable this deduplication by applying `-Z deduplicate-diagnostics=no` to UI tests.
Make Layout::new const
This seems like a reasonable change to make. If we don't provide `Layout:🆕:<T>` as `const`, then users can just instead do the more error prone `Layout::from_size_align_unchecked(mem::size_of::<T>(), mem::align_of::<T>())` for the same effect and an extra `unsafe { }` incantation.
