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.
MGCA: Support for tuple constructors
r? BoxyUwU
part of https://github.com/rust-lang/rust/issues/132980fixesrust-lang/rust#136379fixesrust-lang/rust#138132
i tried to keep implementation very minimal and it's very similar to how structs was implemented with small adjustments
this does not make const constructor like None works, just something like Some(n)
todo:
* ~~tests~~
* write a better description (not sure if needed)
* add more comments and FIXMEs from structs code
Forbid generic parameters in types of #[type_const] items
fixesrust-lang/rust#150614
we enforce the same restriction on `#[type_const]` const items that already exists for const generic parameters - when `generic_const_parameter_types` feature gate is not enabled, the type of a `#[type_const]` item cannot reference generic parameters. implementation follows the same pattern used for const generic parameters. we check if the item has the `#[type_const]` attribute and if the feature gate is disabled, then we apply `RibKind::ConstParamTy` restrictions when visiting the type, which prevents the use of generic parameters.
check is added in three places:
- Free const items (`ItemKind::Const`)
- Trait associated consts (`AssocItemKind::Const` in traits)
- Impl associated consts (`AssocItemKind::Const` in impls)
added tests for new feature, hope i get this task right :>
r? `@BoxyUwU`
