There is no reason (obvious to me) that would prevent us from ignoring
the "simd" part during constexpr eval, assuming there are no clauses.
The potentially controversial part is the change from Equal to Encloses
when we do the context lookup.
Adding a few more reviewers who have been poking around in constant expression evaluation lately.
You should manually re-flow this to the usual 80-col limit.
This comment no longer matches the code. It also suggests that the way to address your issue is to capture the variable into the current frame -- did you explore that approach?
C++20 now has constexpr destructors, but there are also other kinds of special member functions too. It seems like the constraint really is "constant evaluation of a function with SIMD clauses is invalid" and so we might want to go with a more generic diagnostic instead of trying to distinguish between kinds of functions.
The problem is that OpenMP introduces artificial capture statements. I am not sure if/how those can be "merged" into the parent context and in general that is not allowed (e.g., as we allow clauses on SIMD, like private). I feel the comment needs updating and I'll try that.
I copied this from below (see comment). I would assume the two have to stay in sync. All the differentiation of constructor does it to specify where it was found, no? So:
Is there a way to limit the change to only OpenMP captured variables so that we're not changing the semantics for all language modes?
Yeah, they should stay in sync; I don't insist on a change to the diagnostic as part of this review unless you feel like it.
I could reasonably guard this to look for -fopenmp if we want to. The variables themselves are probably not easy to identify. I'll look at it again next week in the hope to make more sense of the intermediate frame and maybe avoid this to spill over to other models.