do something more careful than eval_const_expr

[kevina]

Eval_const_expr is used in the front end in several places. This code quasi-duplicates stuff that trans should probably be doing (in Graydon's words).

Any evaluation of compile-time values should likely be moved to a pass somewhere in the middle end. I assume there is a way to get a compile-time value out of LLVM, but I'm not sure.

[brson]

I don't know how to manage that. trans is rightly letting LLVM do the same work that eval_const_expr does, but eval_const_expr is used for analysis passes that don't have access to LLVM.

[graydon]

Which analysis passes? I'm mostly concerned that the choice of what to evaluate in either place seems ad-hoc, and it's not clear which subsets of the expression language ought to be viable as constants in which context. We should get a clear picture of those. If the result is we do some eval in duplicate (or in 2 phases) that's ok.

[brson]

It's used by enum_variants to get the discriminant, which is used in many places. for example the discriminant is written to the metadata.

It's used in type checking, also to check properties of enum discriminants.

It also looks like it's used for reachability testing in alt expressions.