Implement MVP for opaque generic const arguments

[camelid]

This is meant to be the interim successor to generic const expressions.
Essentially, const item RHS's will be allowed to do arbitrary const
operations using generics. The limitation is that these const items will
be treated opaquely, like ADTs in nominal typing, such that uses of them
will only be equal if the same const item is referenced. In other words,
two const items with the exact same RHS will not be considered equal.

I also added some logic to check feature gates that depend on others
being enabled (like oGCA depending on mGCA).

r? @BoxyUwU

[camelid]

TODO:

• only use AnonConstKind::OGCA for const item RHS's
• add tests
• (less urgent:) don't normalize opaque const items (those with OGCA RHS)
• handle coherence correctly (ambiguous if not definitionally equal)

[BoxyUwU]

When we avoid normalizing type consts to opaque anon consts we need to make sure that the normalization is ambiguous in coherence instead of NoSolution:

#![feature(min_generic_const_args, opaque_generic_const_args)]

#[type_const]
const FOO<const N: usize>: usize = const { N + 1 };

#[type_const]
const BAR<const N: usize>: usize = const { N + 1 };

trait Trait {}

impl Trait for [(); FOO::<1>] {}
impl Trait for [(); BAR::<1>] {}

ie we don't want this code to pass due to the two opaque anon consts being unequal.

[camelid]

Ooh good point 👍

[rustbot]

HIR ty lowering was modified

cc @fmease

[BoxyUwU]

also need to add the coherence test :3

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

fmt: checked 6688 files
tidy check
tidy [rustdoc_json (src)]: `rustdoc-json-types` modified, checking format version
tidy: Skipping binary file check, read-only filesystem
tidy [style (compiler)]: /checkout/compiler/rustc_feature/src/unstable.rs:605: TODO is used for tasks that should be done before merging a PR; If you want to leave a message in the codebase use FIXME
tidy [style (compiler)]: FAIL
tidy [style (tests)]: /checkout/tests/ui/const-generics/associated-const-bindings/dyn-compat-self-const-projections-in-assoc-const-ty.rs:7: line longer than 100 chars
tidy [style (tests)]: FAIL
tidy [features]: /checkout/compiler/rustc_feature/src/unstable.rs:606: no tracking issue for feature opaque_generic_const_args
tidy [features]: FAIL
tidy: The following checks failed: features, style (compiler), style (tests)
Bootstrap failed while executing `--stage 2 test --skip tests --skip coverage-map --skip coverage-run --skip library --skip tidyselftest`
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/rust-tidy --root-path=/checkout --cargo-path=/checkout/obj/build/aarch64-unknown-linux-gnu/stage0/bin/cargo --output-dir=/checkout/obj/build --concurrency=4 --npm-path=yarn` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1612:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1364:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:00:52
  local time: Sun Feb  1 23:34:10 UTC 2026
  network time: Sun, 01 Feb 2026 23:34:10 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[BoxyUwU]

I think we basically don't want this change 🤔 The soundness critical thing for coherence is that normalizing oGCA anon consts is ambiguous. We handle this (incidentally) in normalize_anon_const which will also handle this when normalizing associated constants, not just free consts like we do here.

I would drop this change. I expect this will make diagnostics worse in coherence but I think that's fine for now. Or at least I think we should improve diagnostics of errors involving oGCA anon consts in a different way than complicating soundness critical normalization logic 🤔

[BoxyUwU]

I realise I previously stated:

(less urgent:) don't normalize opaque const items (those with OGCA RHS)

but I disagree with myself now 😆 complicated normalization logic by doing this for diagnostics reasons is pretty meh

[BoxyUwU]

The existing logic here implicitly gives ambiguity during coherence but also outside of coherence which I think is undesirable. In the failure case we should check if goal.predicate.alias.def_id is an oGCA anon const, and if so return NoSolution if we're outside of coherence, otherwise return AMBIGUOUS

If we don't do this I think we'll get type inference errors whenever the new solver tries to normalize oGCA anon consts 🤔 e.g.

//@ compile-flags: -Znext-solver
#![feature(generic_const_items, min_generic_const_args, opaque_generic_const_args)]

#[type_const]
const FOO<const N: usize>: usize = const { N + 1 };

fn foo() {
    let a: [(); FOO::<1>];
}

probably fails under your PR right now?

[BoxyUwU]

i was wrong ^ the evaluate_const here is not try_evalaute_const from in rustc_trait_selection and implicitly turns the HasInfersOrParams cases into Ok. We need to check for oGCA consts here and return ambiguity explicitly in coherence

[BoxyUwU]

@rustbot author

[BoxyUwU]

Suggested change

	// TODO: create tracking issue
	(unstable, opaque_generic_const_args, "CURRENT_RUSTC_VERSION", None),
	(unstable, opaque_generic_const_args, "CURRENT_RUSTC_VERSION", Some(151972)),

[rust-bors]

☔ The latest upstream changes (presumably #152163) made this pull request unmergeable. Please resolve the merge conflicts.