hazohelet added inline comments.

================
Comment at: clang/test/SemaCXX/vartemplate-lambda.cpp:17
+                                                        // 
expected-note{{cannot be used in a constant expression}} \
+                                                        // expected-error 2{{a 
lambda expression may not appear inside of a constant expression}}
 };
----------------
cor3ntin wrote:
> hazohelet wrote:
> > cor3ntin wrote:
> > > This also looks like a regression.
> > > 
> > > The current error is much clearer, can you investigate?
> > > ```
> > > <source>:3:22: error: constexpr variable 't<int>' must be initialized by 
> > > a constant expression
> > >     3 |   static constexpr T t = [](int f = T(7)){return f;}();
> > >       |                      ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > <source>:6:12: note: in instantiation of static data member 'S::t<int>' 
> > > requested here
> > >     6 | int a = S::t<int>;
> > >       |            ^
> > > <source>:3:26: note: non-literal type 'S::(lambda at <source>:3:26)' 
> > > cannot be used in a constant expression
> > >     3 |   static constexpr T t = [](int f = T(7)){return f;}();
> > >       |                          ^
> > > ```
> > > 
> > > Why do we emt 2 errors instead of a single note? Here the error is that 
> > > the initializer is not a constant expression, everything else should be 
> > > notes.
> > "lambda cannot be in constant expression" error is emitted from Sema 
> > against lambda expressions in constant-evaluated contexts in C++14 mode, 
> > and the note is emitted from constexpr evaluator.
> > The Sema-side error is emitted twice because it is emitted both 
> > before/after instantiation.
> > We can suppress one of them by ignoring it when sema is instantiating 
> > variable template initializer.
> > Or we can completely suppress this Sema error against initializers to avoid 
> > duplicate errors from Sema and constexpr evaluator.
> > I think "lambda cannot be in constant expression" Sema error is more 
> > understandable than the constexpr evaluator note "non-literal type cannot 
> > be in constant expression", so I think it is ok to keep one Sema error here.
> So maybe the issue is that we are not making the declaration invalid in sema 
> when we get this error? Can you look into it?
> any opinion @aaron.ballman 
I updated the patch to keep a single sema error here and stop constant 
interpreter from evaluating the initializer by marking declaration invalid. I 
like having one sema error here.


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

https://reviews.llvm.org/D155064

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to