This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults
Update const_generics:default locations
Previously just ignored them, now actually do something about them.
Fix using type check instead of value
Add parsing
This adds all the necessary changes to lower const-generics defaults from parsing.
Change P<Expr> to AnonConst
This matches the arguments passed to instantiations of const generics, and makes it specific to
just anonymous constants.
Attempt to fix lowering bugs
const_evaluatable_checked: Stop eagerly erroring in `is_const_evaluatable`
Fixes#82279
We don't want to be emitting errors inside of is_const_evaluatable because we may call this during selection where it should be able to fail silently
There were two errors being emitted in `is_const_evaluatable`. The one causing the compile error in #82279 was inside the match arm for `FailureKind::MentionsParam` but I moved the other error being emitted too since it made things cleaner imo
The `NotConstEvaluatable` enum \*should\* have a fourth variant for when we fail to evaluate a concrete const, e.g. `0 - 1` but that cant happen until #81339
cc `@oli-obk` `@lcnr`
r? `@nikomatsakis`
const_generics: Dont evaluate array length const when handling yet another error
Same ICE as #82009 except triggered by a different error.
cc ``@lcnr``
r? ``@varkor``
Add diagnostics for specific cases for const/type mismatch err
For now, this adds at least more information so better diagnostics can be emitted for const mismatch errors.
I'm not sure what exactly we want to emit, so I've left notes there temporarily, also to see if this is the right approach
r? ```@lcnr```
cc: ```@estebank```
const_generics: Fix incorrect ty::ParamEnv::empty() usage
Fixes#80561
Not sure if I should keep the `debug!(..)`s or not but its the second time I've needed them so they sure seem useful lol
cc ``@lcnr``
r? ``@oli-obk``
Add better diagnostic for unbounded Abst. Const
~~In the case where a generic abst. const requires a trivial where bound: `where TypeWithConst<const_fn(N)>: ,`,
instead of requiring a where bound, just check that only consts are being substituted in to skip over where check.~~
~~This is pretty sketchy, but I think it works. Presumably, if there is checking for type bounds added later, it can first check nested requirements, and see if they're satisfied by the current `ParamEnv`.~~
Changed the diagnostic to add a better example, which is more practical than what was previously proposed.
r? ```@lcnr```
Add error message for private fn
Attempts to add a more detailed error when a `const_evaluatable` fn from another scope is used inside of a scope which cannot access it.
r? ````@lcnr````
Add a test for #71202Closes#71202
---
Note that the test normally generates this warning:
```
warning: cannot use constants which depend on generic parameters in types
--> test.rs:10:5
|
10 | / const ITEM_IS_COPY: [(); 1 - {
11 | | trait NotCopy {
12 | | const VALUE: bool = false;
13 | | }
... |
26 | | <IsCopy<T>>::VALUE
27 | | } as usize] = [];
| |_____________________^
|
= note: `#[warn(const_evaluatable_unchecked)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #76200 <https://github.com/rust-lang/rust/issues/76200>
```
I added `allow(const_evaluatable_unchecked)`, but maybe we just don't want to add a test for this as the program is not really valid?
Stabilize by-value `[T; N]` iterator `core::array::IntoIter`
Tracking issue: https://github.com/rust-lang/rust/issues/65798
This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135.
This PR does *not* include the corresponding `IntoIterator` impl, which is https://github.com/rust-lang/rust/pull/65819. Instead, an iterator can be constructed through the `new` method.
`new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then, although it will stay stable.
correctly deal with late-bound lifetimes in anon consts
adds support for using late bound lifetimes of the parent context in anon consts.
```rust
#![feature(const_generics)]
const fn inner<'a>() -> usize where &'a (): Sized { 3 }
fn test<'a>() {
let _: [u8; inner::<'a>()];
}
```
The lifetime `'a` is late bound in `test` so it's not included in its generics but is instead dealt with separately in borrowck.
This didn't previously work for anon consts as they have to use the late bound lifetimes of their parent which has
to be explicitly handled.
r? ```@matthewjasper``` cc ```@varkor``` ```@eddyb```
Add check for `[T;N]`/`usize` mismatch in astconv
Helps clarify the issue in #80506
by adding a specific check for mismatches between [T;N] and usize.
r? `@lcnr`
