Repository navigation
do something more careful than eval_const_expr #1417
Description
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.
Reacted by Felipe S. S. Schneider
Activity
brson commentedon Jan 5, 2012
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 commentedon Jan 31, 2012
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 commentedon Jan 31, 2012
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.
Merge pull request rust-lang#1417 from rust-lang/implement_xgetbv
Enable 2021 edition globally for rustfmt (rust-lang#1417)
Automatic toolchain upgrade to nightly-2023-11-11 (rust-lang#2870)
Rollup merge of rust-lang#137788 - jieyouxu:bump-compiler-cc, r=lqd,K…
Unrolled build for rust-lang#137788
Update to `wasm32-wasip1`-based testing
Update to `wasm32-wasip1`-based testing
Merge rust-lang#1417
Auto merge of rust-lang#1417 - RalfJung:libstd-rebuilds, r=RalfJung