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

[lcnr]

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

[griffi-gh]

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

[tarcieri]

@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.

[jhpratt]

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.

[eminence]

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>`

[clarfonthey]

It seems that the main blocker to stabilising this is:

Author an RFC explaining the current state of the feature since it has significantly diverged from original RFC

Although I'm not exactly sure what exactly these differences are, and whether it's needed based after rust-lang/rfcs#3535 has clarified the details on constant patterns. Would someone be willing to update the description to clarify the details on this, and which RFC it's referring to for the original details?

(I know that there are other open issues for this feature, although it feels like the semantic clarification is the most difficult to resolve.)