Skip to content

MGCA: Support literals as direct const arguments #150618

@BoxyUwU

Description

@BoxyUwU

Currently we have a parser special case under MGCA that Foo::<1> is allowed without an explicit const block. E.g. normally we require Foo::<const { 1 + 1 }> for non-direct const arguments, but literals are special.

This special case only applies to the "top level" of a const argument, not to field initialisers of struct expressions or in the future element expressions of arrays/tuples or tuple constructors. It would maybe be possible to extend this special case to those positions but it would be involved and kind of annoying.

Instead I would like to support literals as direct const arguments without an anon const. ie a hir::ConstArgKind::Literal. This should let us clean up some of the parser code for mgca and make using the feature nicer as literals will be less boilerplate.

These should lower directly to a ConstKind::Value. However, this isn't possible if we dont have type information for what the literal is. This in theory is only a problem for integer and float literals. I expect we should:

  • Use the explicit disambiguator on the literal, ie 1_i32
  • Look at the type of the const parameter we're lowering the const argument for. E.g. struct Foo<const N: usize>; type Bar = Foo<1>; We can't normalize this type and it may be an inference variable so this doesn't work 100% of the time.

And if we can't get a type from there we can emit an error during HIR ty lowering to explicitly annotate the type. If we wanted to not require an explicit type this would motivate addition of a ConstKind::Expr(Expr::Literal, but I would like to avoid that if possible.

We may actually want to use this representation on stable to get rid of the perf optimization where we lower directly from a ConstArgKind::Anon to a ConstKind::Value. Not worth doing in the first implementation of this however as this will have the same issues as #149774.

Metadata

Metadata

Assignees

Labels

A-const-genericsArea: const generics (parameters and arguments)E-mediumCall for participation: Medium difficulty. Experience needed to fix: Intermediate.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.F-min_generic_const_args`#![feature(min_generic_const_args)]`

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions