On Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote: > Using std::is_constant_evaluated directly in a loop condition is, as the > paper says, unlikely and "horrendous code", so I'm not concerned about > surprising effects, though I guess we should check for it with > maybe_warn_for_constant_evaluated.
Ok, though guess the question is what to say about it. Because unlike the existing cases in maybe_warn_for_constant_evaluated where it always evaluates to true or always to false depending on where, in the trivial empty iteration statements it evaluates to always true or always false depending or sometimes true, sometimes false, depending on if the condition is a constant expression that evaluates to true (then it is always true), or if in immediate function (also always true), or if not in constexpr function (then always false), or in constexpr function (then it might be true or false). Not sure how exactly to word that. Maybe just say that it is horrendous code to use std::is_constant_evaluated () in trivial empty iteration statement conditions ;) What about loops with non-empty bodies or other reasons why they aren't trivial empty iteration statements? Shall we do maybe_warn_for_constant_evaluated for those (with the current wording, false in non-constexpr fn, true in consteval)? > > So, the patch below attempts to discover trivially empty iteration > > statements at cp_fold time if it is the final mce_false folding, > > attempts to maybe_constant_value with mce_false evaluate the conditions > > and replaces it with the returned value if constant non-zero. > > Please refactor this code to share most of the implementation between the > loop types. Will do. Jakub