Next-gen Trait Solver does not implement Generic Const Expressions

[GamingLiamStudios]

I was fluffing around with different generic stuff and ended up enabling the Next-gen solver, where I realized that it looked like Generic Const Expressions just don't work at all.

This code seems to work fine with the default trait solver, but when you enable the -Znext-solver flag, it throws a normalization error.

#![feature(generic_const_exprs)]
pub struct Vec<T, const N: usize>
where
    [T; N * N]: Sized,
{
    packed: [T; N * N],
}

I understand this is all very unstable stuff, but thought it was still probably slightly unintended behavior at the least.

Meta

rustc --version --verbose:

rustc 1.82.0-nightly (100fde524 2024-08-28)
binary: rustc
commit-hash: 100fde5246bf56f22fb5cc85374dd841296fce0e
commit-date: 2024-08-28
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0

Backtrace

error[E0284]: type annotations needed: cannot normalize `Vec<T, N>::packed::{constant#0}`
 --> src/main.rs:6:13
  |
6 |     packed: [T; N * N],
  |             ^^^^^^^^^^ cannot normalize `Vec<T, N>::packed::{constant#0}`

[compiler-errors]

I understand this is all very unstable stuff, but thought it was still probably slightly unintended behavior at the least.

It's unstable, but it is intended. We've intentionally opted to not implement any of this GCE behavior in the new solver for the time being.

[GamingLiamStudios]

Fair enough.

[matthieu-m]

@compiler-errors Would you have an idea of when this will be implemented?

---

I understand that generic_const_exprs have been unstable all along, yet at the same time this case of "simple" arithmetic expressions kinda just happen any time one goes beyond simplistic examples with const generics, and all those codebases are now stranded (cannot keep upgrading nightly), so I'd like to understand better where we're going, and if short-term work-arounds are available.

1. Is the implementation of "simple" arithmetic expressions off the table for several versions, or is just a matter of 1 or 2 more versions?
2. If the next trait-solver is not planned to handle those expression for a while, is it possible to remove the requirement to use -Znext-solver to use the feature, so that codebases for which it used to work can simply continue tracking nightly?
3. More radically, should we just remove those bounds and accept that N * N may fail during monomorphization instead? (I seem to remember the intention that they would be temporary)
4. Is there any other solution/work-around?

And just to be clear: thanks for your work, and it's not the end of the world if it takes another 6 months... it just means no feedback on other features in the meantime, from those stranded codebases.

[compiler-errors]

What are you even using the new solver for?

[matthieu-m]

What are you even using the new solver for?

That's... an interesting question actually.

rustc 1.82+ refuses to compile code with #![feature(effects)] without -Znext-solver.

I distinctly remember having to add #![feature(effects)] to appease rustc 1.81- for some of the const-related stuff. If I remember correctly, it would otherwise ICE.

A test on the playground with the current nightly seems to indicate that effects are no longer necessary to build #![feature(generic_const_exprs)] code, so perhaps removing #![feature(effects)] is a potential solution to not having to use the next solver. I would need to test that out on our codebase, hopefully by next week.