Introduce `feature(generic_const_parameter_types)` #137617

BoxyUwU · 2025-02-25T13:53:01Z

Allows to define const generic parameters whose type depends on other generic parameters, e.g. Foo<const N: usize, const ARR: [u8; N]>;

Wasn't going to implement for this for a while until we could implement it with bad_inference.rs resolved but apparently the project simd folks would like to be able to use this for some intrinsics and the inference issue isn't really a huge problem there aiui. (cc @workingjubilee )

rustbot · 2025-02-25T13:53:06Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-02-25T13:53:08Z

HIR ty lowering was modified

cc @fmease

BoxyUwU · 2025-02-25T13:56:23Z

tests/ui/const-generics/issues/issue-62878.full.stderr

-   |
-   = note: const parameters may not be used in the type of const parameters


I couldn't figure out how to retain this note as now we just fail to resolve the N (i.e. it's res is a Res::Err) instead of previously where it would resolve to N and then we'd error when validating the resolution.

Honestly though I think this note didn't help very much anyway. It's almost a complete copy of the top level error message where its only new information is the kind of parameter that N is. I don't expect that to be very useful information and we don't provide it when you use a forward declared generic parameter in a parameter's default either:

error[E0128]: generic parameters with a default cannot use forward declared identifiers --> src/lib.rs:1:21 | 1 | struct Foo<T = [u8; N], const N: usize = 1>(T); | ^ defaulted generic parameters cannot be forward declared

compiler/rustc_feature/src/unstable.rs

workingjubilee · 2025-02-25T14:50:40Z

tests/ui/const-generics/generic_const_parameter_types/bad_inference.rs

+    // Requires inferring `T`/`N` from `12_u8` and `2` respectively.
+    let a = foo::<_, _, { [12_u8; 2] }>();


hm, is it different for these cases?

fn main() { let a = foo::<_, _, { [5_u8, 6] }>(); let b: [u8; 2] = foo::<_, _, { [5, 6] }>(); }

those would both error, the requirement is that from looking at the generic arguments to foo you must be able to determine the full inferred type of the const parameter without performing any type inference or trait solving. (though this is only the case when the argument is an anonymous constant, as opposed to a _ or a usage of a generic parameter or some mgca arg)

jieyouxu · 2025-02-25T15:18:45Z

r? types

compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs

tests/ui/const-generics/generic_const_parameter_types/forward_declared_type.rs

tests/ui/const-generics/generic_const_parameter_types/mismatched_length.rs

lcnr

looking good :3

compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs

lcnr

final nit, then r=me

compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

BoxyUwU · 2025-02-28T12:12:08Z

(changed impl non trivially in how we handle paths to const params so needs reivew again)

lcnr · 2025-02-28T13:00:22Z

compiler/rustc_type_ir/src/visit.rs

@@ -326,6 +326,12 @@ pub trait TypeVisitableExt<I: Interner>: TypeVisitable<I> {
        self.has_type_flags(TypeFlags::HAS_FREE_REGIONS)
    }

+    fn has_regions(&self) -> bool {
+        self.has_type_flags(
+            TypeFlags::HAS_FREE_REGIONS | TypeFlags::HAS_RE_ERASED | TypeFlags::HAS_RE_BOUND,


🤔 we should support bound regions and not check for them

maybe has_free_or_erased_regions... or actually, has_free_regions should include RE_ERASED imo, so we should have has_free_non_erased_regions :<

Hmm yeah ur right there's no real reason to forbid bound regions. I was being a bit overly conservative here :3 I just removed has_regions entirely because if its only FREE_REGIONS | ERASED then its not that bad to just do it in-line in args lowering.

It is somewhat weird that has_free_regions doesnt proc on RE_ERASED 🤔

lcnr

nit, then r=me, i don't rly care how u handle it

BoxyUwU · 2025-02-28T20:46:10Z

rebased and resolved nit

@bors r=lcnr

bors · 2025-02-28T20:46:13Z

📌 Commit df5b279 has been approved by lcnr

It is now in the queue for this repository.

…pes, r=lcnr Introduce `feature(generic_const_parameter_types)` Allows to define const generic parameters whose type depends on other generic parameters, e.g. `Foo<const N: usize, const ARR: [u8; N]>;` Wasn't going to implement for this for a while until we could implement it with `bad_inference.rs` resolved but apparently the project simd folks would like to be able to use this for some intrinsics and the inference issue isn't really a huge problem there aiui. (cc `@workingjubilee` )

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#136503 (Tweak output of const panic diagnostic) - rust-lang#137390 (tests: fix up new test for nocapture -> capture(none) change) - rust-lang#137617 (Introduce `feature(generic_const_parameter_types)`) - rust-lang#137719 (Add missing case explanation for doc inlined re-export of doc hidden item) - rust-lang#137763 (Use `mk_ty_from_kind` a bit less, clean up lifetime handling in borrowck) - rust-lang#137769 (Do not yeet `unsafe<>` from type when formatting unsafe binder) - rust-lang#137776 (Some `rustc_transmute` cleanups) - rust-lang#137800 (Remove `ParamEnv::without_caller_bounds`) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#137617 - BoxyUwU:generic_const_parameter_types, r=lcnr Introduce `feature(generic_const_parameter_types)` Allows to define const generic parameters whose type depends on other generic parameters, e.g. `Foo<const N: usize, const ARR: [u8; N]>;` Wasn't going to implement for this for a while until we could implement it with `bad_inference.rs` resolved but apparently the project simd folks would like to be able to use this for some intrinsics and the inference issue isn't really a huge problem there aiui. (cc ``@workingjubilee`` )

…r=BoxyUwU Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs In rust-lang#137617, the `ConstParamTy` rib was adjusted to act kinda like the `ForwardGenericParamBan`. However, this means that it no longer served its purpose banning generics from *parent items*. Although we still are checking for param type validity using the `ConstParamTy_` trait, which means that we weren't accepting code we shouldn't, I think it's a bit strange for us not to be rejecting code like this during *resolution* and instead letting these malformed const generics leak into the type system: ```rust trait Foo<T> { fn bar<const N: T>() {} } ``` This PR does a few things: 1. Introduce a `ForwardGenericParamBanReason` enum, and start using the `ForwardGenericParamBan` rib to ban forward-declared params in const tys when `generic_const_parameter_types` is enabled. 2. Start using the `ConstParamTy` rib to ban *all* generics when `generic_const_parameter_types` is disabled. 3. Improve the diagnostics for both of the cases above, and for forward-declared params in parameter defaults too :3 r? `@BoxyUwU` or reassign

rustbot assigned jieyouxu Feb 25, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 25, 2025

BoxyUwU commented Feb 25, 2025

View reviewed changes

compiler/rustc_feature/src/unstable.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

workingjubilee reviewed Feb 25, 2025

View reviewed changes

rustbot added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Feb 25, 2025

rustbot assigned lcnr and unassigned jieyouxu Feb 25, 2025

BoxyUwU force-pushed the generic_const_parameter_types branch from 6c02c7d to 2fa5b32 Compare February 25, 2025 17:02