[PATCH] D106302: Implement P1937 consteval in unevaluated contexts

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.


================
Comment at: clang/test/SemaCXX/cxx2a-consteval.cpp:612
+static_assert(is_same<long, T>::value);
+
+} // namespace unevaluated
----------------
cor3ntin wrote:
> aaron.ballman wrote:
> > cor3ntin wrote:
> > > cor3ntin wrote:
> > > > aaron.ballman wrote:
> > > > > Here's an interesting test case:
> > > > > ```
> > > > > #include <typeinfo>
> > > > > 
> > > > > struct S {
> > > > >   virtual void f();
> > > > > };
> > > > > 
> > > > > struct D : S {
> > > > >   void f() override;
> > > > > };
> > > > > 
> > > > > consteval S *get_s() { return nullptr; }
> > > > > 
> > > > > void func() {
> > > > >   (void)typeid(*get_s());
> > > > > }
> > > > > ```
> > > > > `typeid` still needs to evaluate its operand (due to the polymorphic return type of `*get_s()`), and so you should get a diagnostic about evaluating the side effects by calling `get_s()`. I think this then runs into https://eel.is/c++draft/expr.const#13.sentence-3 and we should diagnose?
> > > > Not sure!
> > > > Also, in the context of this pr, the question is also whether `decltype(typeid(*get_s()))` should be ill-formed I think
> > > Actually, I'm reading the wording again and I really don't know anymore.
> > > `get_s()` is a constant expression, right?
> > > `*get_s()` is not, I think but is that relevant here
> > > 
> > > I played with a bunch of things in the code but the more I look at it the less I'm convinced an action is needed.
> > The changes to `Sema::CheckForImmediateInvocation()` to check for an unevaluated context and https://eel.is/c++draft/expr.const#13.sentence-3 that say an immediate invocation shall be a constant expression are what got me thinking about this code snippet in the first place. I was trying to decide whether `isUnevaluatedContext()` is correct or not because with `typeid`, it is potentially evaluated (so sometimes it's unevaluated).
> > 
> > Interestingly, everyone comes up with a different answer: https://godbolt.org/z/TqjGh1he6 and I don't (yet) know who is correct.
> @rsmith Can you enlighten us here?
> My take is that `get_s()` is a constant expression and therefore an immediate invocation. independently of what `*get_s()` does but I'm not sure if that's a correct reading.  
> 
> Thanks a lot!
There are a few different cases here and I don't think any compiler is getting them all right.

```
struct S {
  void f();
};
struct T {
  virtual void f();
};

consteval S *null_s() { return nullptr; }
consteval S *make_s() { return new S; }
consteval T *null_t() { return nullptr; }
consteval T *make_s() { return new T; }

void func() {
  (void)typeid(*null_s()); // #1
  (void)typeid(*make_s()); // #2
  (void)typeid(*null_t()); // #3
  (void)typeid(*make_t()); // #4
}
```

Here, #3 and #4 pass an lvalue of polymorphic class type to `typeid`, so the arguments to those `typeid`s are potentially evaluated. #1 and #2 pass an lvalue of non-polymorphic class type, so those arguments are unevaluated operands. So we have two immediate invocations: the `null_t()` call and the `make_t()` call.

Lines #1 and #2 are valid because there's no immediate invocation to check. (Clang and GCC get this wrong and reject #2.)
Line #3 is valid because the call to `null_t()` is a constant expression. (MSVC gets this wrong for reasons I don't understand.)
Line #4 is ill-formed because the call to `make_t()` is not a constant expression, because it returns a heap allocation.

The way we handle `typeid` in general is to parse its operand as an unevaluated operand, and then later `TransformToPotentiallyEvaluated` if we find it's a glvalue of or pointer to polymorphic class type. If you find the above testcase isn't handled correctly, you may need to make some changes in `TransformToPotentiallyEvaluated` to trigger the proper rebuilding. (You might need to force it to transform `CallExpr`s that refer to `consteval` functions even if nothing within them have changed, for example.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106302/new/

https://reviews.llvm.org/D106302