| Age | Commit message (Collapse) | Author | Lines |
|
r=oli-obk
Deeply deny fn and raw ptrs in const generics
I think this is right -- just because we wrap a fn ptr in a wrapper type does not mean we should allow it in a const parameter.
We now reject both of these in the same way:
```
#![feature(adt_const_params)]
#[derive(Eq, PartialEq)]
struct Wrapper();
fn foo<const W: Wrapper>() {}
fn foo2<const F: fn()>() {}
```
This does regress one test (`src/test/ui/consts/refs_check_const_eq-issue-88384.stderr`), but I'm not sure it should've passed in the first place.
cc: ``@b-naber`` who introduced that test^
fixes #99641
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
Use correct substs in enum discriminant cast
Fixes https://github.com/rust-lang/rust/issues/97634
r? ```@lcnr```
|
|
|
|
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
|
|
|
|
|
|
TaKO8Ki:fix-misleading-cannot-infer-type-for-type-parameter-error, r=oli-obk
Fix misleading `cannot infer type for type parameter` error
closes #93198
|
|
fix ci error
emit err for `impl_item`
|
|
|
|
|
|
Handle mismatched generic param kinds in trait impls betterly
- Check that generic params on a generic associated type are the same as in the trait definition
- Check that const generics are not used in place of type generics (and the other way round too)
r? `@lcnr`
|
|
|
|
|
|
|
|
|
|
|
|
Enforce static lifetimes in consts during late resolution
This PR moves the handling of implicitly and explicitly static lifetimes in constants from HIR to the AST.
|
|
|
|
|
|
typeck and that they are Copy (with proper lifetime checks) in borrowck
|
|
|
|
|
|
diagnostics: use correct span for const generics
Fixes #95616
|
|
|
|
Fixes #95616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Directly use ConstValue for single literals in blocks
Addresses the minimal repro in https://github.com/rust-lang/rust/issues/92186, but doesn't fix the underlying problem (which would be solved by solving the anon subst problem afaict).
I do, however, think that it makes sense in general to treat single literals in anon blocks as const values directly, especially in light of the problem that the issue refers to (anon const evaluation being postponed until infer variables in substs can be resolved, which was introduced by https://github.com/rust-lang/rust/pull/90023), i.e. while we do get warnings for those unnecessary braces, we should try to avoid errors caused by those braces if possible.
|
|
|
|
|
|
Add tests fixed by #90023
The following issues were fixed by https://github.com/rust-lang/rust/pull/90023
Fixes https://github.com/rust-lang/rust/issues/79674
Fixes https://github.com/rust-lang/rust/issues/83765
Fixes https://github.com/rust-lang/rust/issues/86033
Fixes https://github.com/rust-lang/rust/issues/90318
Fixes https://github.com/rust-lang/rust/issues/88468
The following issues were duplicates of https://github.com/rust-lang/rust/issues/90654
Fixes https://github.com/rust-lang/rust/issues/86850
Fixes https://github.com/rust-lang/rust/issues/89022
r? ````@jackh726````
|
|
|
|
Allow for failure of subst_normalize_erasing_regions in const_eval
Fixes https://github.com/rust-lang/rust/issues/72845
Using associated types that cannot be normalized previously resulted in an ICE. We now allow for normalization failure and return a "TooGeneric" error in that case.
r? ```@RalfJung``` maybe?
|
|
Skip reborrows in AbstractConstBuilder
Fixes https://github.com/rust-lang/rust/issues/90455
Temporary fix to prevent confusing diagnostics that refer to implicit borrows and derefs until we allow borrows and derefs on constant expressions.
r? `@oli-obk`
|
|
|
|
|
|
Postpone the evaluation of constant expressions that depend on inference variables
Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected, hence no real error was ever encountered, but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring.
We now postpone the evaluation of these constants, so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present.
Fixes https://github.com/rust-lang/rust/issues/89320
Fixes https://github.com/rust-lang/rust/issues/89146
Fixes https://github.com/rust-lang/rust/issues/87964
Fixes https://github.com/rust-lang/rust/issues/87470
Fixes https://github.com/rust-lang/rust/issues/83288
Fixes https://github.com/rust-lang/rust/issues/83249
Fixes https://github.com/rust-lang/rust/issues/90654
I want to thank `@BoxyUwU` for cooperating on this and for providing some help.
r? `@lcnr` maybe?
|