`const` blocks as a `mod` item
Tracking issue: rust-lang/rust#149226
This adds support for writing `const { ... }` as an item in a module. In the current implementation, this is a unique AST item that gets lowered to `const _: () = const { ... };` in HIR.
rustfmt support included.
TODO:
- `pub const { ... }` does not make sense (see rust-lang/rust#147136). Reject it. Should this be rejected by the parser or smth?
- Improve diagnostics (preferably they should not mention the fake `_` ident).
FCW Lint when using an ambiguously glob imported trait
Related to rust-lang/rust#147992.
Report a lint when using an ambiguously glob import trait, this is a FCW because this should not be allowed.
r? @petrochenkov
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#150767 (Allow invoking all help options at once)
- rust-lang/rust#150886 (Added mGCA related tests)
- rust-lang/rust#151245 (Explicitly list crate level attrs)
- rust-lang/rust#151268 (Fix ICE on inconsistent import resolution with macro-attributed extern crate)
- rust-lang/rust#151275 (Normalize type_const items even with feature `generic_const_exprs`)
- rust-lang/rust#151288 (Use `find_attr` instead of `attr::contains_name` in `lower_const_item_rhs`)
- rust-lang/rust#151321 (Port #![no_main] to the attribute parser.)
r? @ghost
The problem is that when a macro expand to `compile_error!` because
its input is malformed, the actual error message from the
`compile_error!` might be hidden in a long list of other messages about
using items that should have otherwise been generated by the macro.
So suppress error about missing items in that module.
Fixes issue 68838
Add an additional help note to the ambiguity lint error
This PR adds an additional help note to the ambiguity lint error output to ask users updating their dependencies. This hopefully helps with cases like rust-lang/rust#149845 where newer crate versions are fixed.
r? @petrochenkov
Clean up `rustc_attr_parsing`
Follow-up of rust-lang/rust#150934.
It removes the `Option<>` wrapping for `SharedContext::target` field and completely removed the `target_id` field. Considering this type contains a closure and never updates its `target_id` field, there is no need to keep it around, it can be used directly in the lint emitter.
r? @JonathanBrouwer
Use `default_field_values` more in `Resolver`
Extend more ways of building `FxHashSet`, `FxHashMap`, `UnordSet`, `UnordMap` and `DisambiguatorState` in `const` contexts to allow for more fields in `Resolver` to have a default value. `FxIndexSet`/`FxIndexMap` are still outstanding and not const-buildable.
r? @petrochenkov
This PR adds an additional help note to the ambiguity lint error output
to ask users updating their dependencies. This hopefully helps with
cases like https://github.com/rust-lang/rust/issues/149845 where newer crate versions are fixed.
The opposite ordering was a consistent source of confusion during debuggingю
`report_conflict` actually used an incorrect order due to similar confusion.
Recognize potential `impl<const N: usize>` to `impl<N>` mistake
When encountering code like `impl<N> Bar<N> for [u8; N]`, suggest `impl<const N: Type> Bar<N> for [u8; N]` as a possibility.
```
error[E0423]: expected value, found type parameter `T`
--> $DIR/issue-69654.rs:5:25
|
LL | impl<T> Bar<T> for [u8; T] {}
| - ^ not a value
| |
| found this type parameter
|
help: you might have meant to write a const parameter here
|
LL | impl<const T: Type> Bar<T> for [u8; T] {}
| +++++ ++++++
```
Addresses "case 3" from rust-lang/rust#84327.
When encountering code like `impl<N> Bar<N> for [u8; N]`, suggest `impl<const N: Type> Bar<N> for [u8; N]` as a possibility.
```
error[E0423]: expected value, found type parameter `T`
--> $DIR/issue-69654.rs:5:25
|
LL | impl<T> Bar<T> for [u8; T] {}
| - ^ not a value
| |
| found this type parameter
|
help: you might have meant to write a const parameter here
|
LL | impl<const T: /* Type */> Bar<T> for [u8; T] {}
| +++++ ++++++++++++
```
Currently all core and std macros are automatically added to the prelude
via #[macro_use]. However a situation arose where we want to add a new macro
`assert_matches` but don't want to pull it into the standard prelude for
compatibility reasons. By explicitly exporting the macros found in the core and
std crates we get to decide on a per macro basis and can later add them via
the rust_20xx preludes.
mGCA: Support array expression as direct const arguments
tracking issue: rust-lang/rust#132980resolve: rust-lang/rust#150612
Support array expression as direct const arguments (e. g. [1, 2, N]) in min_generic_const_args.
todo:
* [x] Rebase another mGCA PR
* [x] Add more test case
* [x] Modify clippy code
resolve: Use `Macros20NormalizedIdent` in more interfaces
It allows to avoid expensive double normalization in some cases.
This is an attempt to fix the perf regressions from https://github.com/rust-lang/rust/pull/149681.
resolve: Factor out and document the glob binding overwriting logic
Also, avoid creating fresh name declarations and overwriting declarations in modules to update some fields in `DeclData`, when possible.
Instead, change the fields directly in `DeclData` using cells.
Unblocks https://github.com/rust-lang/rust/pull/149195.
Vadim Petrochenkov