Support const generics

[flodiebold]

There's a bunch of stuff we need to implement to support const generics at least enough to get method resolution right in simple cases:

• lower const parameters and array sizes as bodies (Lower const parameters #7434)
• represent const parameters in the type checker: this (like supporting lifetime parameters) will mean fixing a bunch of places in hir_ty that currently assume only type parameters exist. A good place to start is probably the Generics helper in hir_ty's util.rs
• use Chalk's unification logic instead of ours that doesn't take consts into account (I'm working on this)
• represent consts in types, at least simple numbers:
  • this means changing InternedConcreteConst in our Interner from () to an enum that can represent these numbers
  • then we need to implement the const_eq method on Interner
• evaluate const bodies: there should be a query that takes a const body and tries to evaluate it, returning a Result<Binders<Const>, ConstEvalError> that can be either a concrete const, a BoundVar referring to a const param, or an error if the expression is too complicated. We'll want to handle errors differently depending on the situation (while inferring bodies, we could replace them by const variables, for example). We should stick to only evaluating simple integer literals for now. We'll need to call this query during type lowering.
  • this would basically also get us most of the way to Feature: show values of constants #8497
  • this should also fix Incorrect resolution of Nalgebra 0.26's fixed-size Vector/Matrix constructors #8654 since our method resolution will then take the const values into account
  • to represent more complicated const generics like { N + 1 } (where N is a const param), we need support in Chalk for unevaluated consts that doesn't exist yet
• expand the const evaluation logic: we shouldn't put too much work into this, but a good subset might be integer literals, consts and maybe the standard binary operations

[matklad]

cc rust-lang/compiler-team#453

[matklad]

I also wonder, what would it take us to “just use miri”, just like we “just use chalk” today (to clarify, I personally know very little at all about how all this is supposed to work)?

[flodiebold]

Miri seemed very entangled with compiler internals when I checked; having the shared type library might be a first step towards that though.

[flodiebold]

Regarding the MCP, in the end we just use Chalk's representation, so 🤷‍♂️

[bjorn3]

Miri can't be used without TyCtxt. Disentangling it is probably going to be pretty hard. It needs everything from the full type system to the type layout calculation to MIR lowering.

[eggyal]

I presume the long-term vision is that, as more and more of rustc is "librarified", RA will increasingly be able to depend on those libraries and (eventually) use them to lower all the way to MIR (whence Miri could be used for const eval etc, or indeed that MIR could be interpreted/lowered to machine code e.g. for #8420)?

Assuming that is the vision, is there somewhere that the broad brush strokes for getting there have been sketched out (perhaps a tracking-issue or similar)? Maybe by breaking the goal into more manageable stages, contributions toward reaching it can be coordinated?

[flodiebold]

The next step right now is the shared type library and Chalk integration in rustc. That would unblock extracting more parts of rustc. There is no overarching long-term plan right now.