Tracking Issue for more complex const parameter types: feature(adt_const_params)

This is a tracking issue for allowing more const parameter types.
The feature gate for this issue is #![feature(adt_const_params)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Most of the work here will be coordinated in the #project-const-generics stream on zulip.

Implement valtrees
deal with structural equality
Figure out which types should be allowed as const parameter types and how
Investigate ICEs around not-wf const arguments (e.g. ICE: expected int of size 8, but got size 1 in rustc_middle/src/ty/consts/int.rs with feature adt_const_params #131052 ICE: InterpErrorInfo(InterpErrorInfoInner { kind: UndefinedBehavior(BoundsCheckFailed #129095 ICE: unable to construct a valtree for the unevaluated constant #128232)
Ensure no forwards compatibility issues with min_generic_const_args
Finalize symbol mangling decision for values of arbitrary types (Value mangling #61486 [RFC2603] Extend <const> to include str and structural constants. rfcs#3161)
Document feature
Stabilization report with lang FCP explaining all the differences between rfc and current impl

Unresolved Questions

Is the v0 mangling setup for adt_const_params forwards compatible with unsized_const_params (Tracking Issue for unsized const parameter types: feature(unsized_const_params) #128028)

cc @rust-lang/project-const-generics

Rollup merge of rust-lang#95175 - lcnr:adt_const_params-tracking-issu…

ices/97047-1.rs: fixed with no errors

ices/97047-2.rs: fixed with no errors

ices/98813.rs: fixed with errors

ices/99641.sh: fixed with errors

I think at least simple enums without assigned values should be allowed for now

@griffi-gh

@griffi-gh I agree. However, in the meantime if you have an e.g. repr(u64) C-style enum, you can cast it with as u64 (or whatever integer type) to sort of fake being const generic around an enum, and that works fine even in const contexts, while also hopefully being trivially upgradable to adt_const_params in the future.

For what it's worth, I am currently hacking around this in time by encoding a struct into a u128, passing as a const generic, and decoding it back to the original struct. All at compile time, as the values are then associated constants. This approach is tedious, but it works for everything up to 16 bytes in size.

Once place where adt_const_params really shines is in diagnostics. Consider the following stable code, which casts a repr(u8) enum, to be used in a const generic:

#[repr(u8)]
pub enum Facing {
    Up,
    Down,
}

pub struct Card<const FACING: u8> {
    // would normally have a "suit" and "number" field
}

pub fn foo(card: Card<{Facing::Up as u8}>) {
    let _: Card<{Facing::Down as u8}> = card;
}

   |
12 |     let _: Card<{Facing::Down as u8}> = card;
   |            --------------------------   ^^^^ expected `1`, found `0`
   |            |
   |            expected due to this
   |
   = note: expected struct `Card<1>`
              found struct `Card<0>`

But with a real enum and adt_const_params, the error message is much clearer:

   |
14 |     let _: Card<{Facing::Down}> = card;
   |            --------------------   ^^^^ expected `Facing::Down`, found `Facing::Up`
   |            |
   |            expected due to this
   |
   = note: expected struct `Card<Facing::Down>`
              found struct `Card<Facing::Up>`

Unrolled build for rust-lang#129208

Rollup merge of #129208 - veluca93:adt_const_fix, r=BoxyUwU

Rollup merge of rust-lang#130344 - Jaic1:fix-116306, r=BoxyUwU

Unrolled build for rust-lang#130344

Rollup merge of rust-lang#131038 - onkoe:fix/adt_const_params_leak_11…

Unrolled build for rust-lang#131038

DRY out Monty params between const and non-const forms

Unify `ConstMontyParams` and `MontyParams`

Unify `ConstMontyParams` and `MontyParams` (#873)

Navigation Menu

Repository navigation

Tracking Issue for more complex const parameter types: `feature(adt_const_params)` #95174

About tracking issues

Steps

Unresolved Questions

18 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for more complex const parameter types: feature(adt_const_params) #95174

Description

About tracking issues

Steps

Unresolved Questions

Activity

griffi-gh commented on Oct 14, 2022

tarcieri commented on Oct 14, 2022

jhpratt commented on Oct 15, 2022

mqudsi commented on Nov 6, 2022

eminence commented on Nov 22, 2022

18 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking Issue for more complex const parameter types: `feature(adt_const_params)` #95174