royjacobson marked an inline comment as not done.
royjacobson added inline comments.
================
Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1037-1041
+def err_static_mutable_lambda : Error<
+ "lambda cannot be both mutable and static">;
+def err_static_lambda_captures : Error<
+ "a static lambda cannot have any captures">;
+def note_lambda_captures : Note<"captures declared here">;
----------------
aaron.ballman wrote:
> royjacobson wrote:
> > aaron.ballman wrote:
> > > royjacobson wrote:
> > > > aaron.ballman wrote:
> > > > > These are semantic errors, not parsing ones. This means these will be
> > > > > diagnosed when parsing the lambda rather than when instantiating it.
> > > > > I don't think that matters for the cast of combining `mutable` and
> > > > > `static`, but I'm less certain about "have any captures" because of
> > > > > cases like:
> > > > > ```
> > > > > template <typename... Types>
> > > > > auto func(Types... Ts) {
> > > > > return [Ts...] { return 1; };
> > > > > }
> > > > >
> > > > > int main() {
> > > > > auto lambda = func();
> > > > > }
> > > > > ```
> > > > > I'm pretty sure that lambda has no captures for that call, but it
> > > > > could have captures depending on the instantiation.
> > > > >
> > > > > Actually, from some off-list discussion with @erichkeane, even
> > > > > mutable and static are a problem in code like:
> > > > > ```
> > > > > template <typename Ty>
> > > > > void func(T t) {
> > > > > if constexpr (Something<T>) {
> > > > > [](){};
> > > > > } else {
> > > > > [t](){};
> > > > > }
> > > > > ```
> > > > > where the lambda is in a discarded statement.
> > > > >
> > > > > So I think these might need to change to be Sema diagnostics (and we
> > > > > should add some additional test coverage).
> > > > From https://eel.is/c++draft/expr.prim.lambda.general#4
> > > >
> > > > > If the lambda-specifier-seq contains static, there shall be no
> > > > > lambda-capture
> > > >
> > > > So this should be a parsing error. Or maybe I don't understand what
> > > > you're saying. There are no static lambdas in your examples so I'm not
> > > > sure how they're related.
> > > >
> > > > So this should be a parsing error. Or maybe I don't understand what
> > > > you're saying.
> > >
> > > Parsing errors are where the grammar disallows something, generally. The
> > > rest are semantic diagnostics (e.g., we can parse the construct just
> > > fine, but we diagnose when turning it into an AST node because that's the
> > > point at which we have complete information about what we've parsed).
> > >
> > > That said, my concern was mostly around SFINAE situations. My
> > > recollection is that SFINAE traps do not cover parsing errors only type
> > > substitution errors. So for my first example, I would expect there to be
> > > no parsing error despite specifying a capture list because that capture
> > > list can be empty when the pack is empty, but we would get a SFINAE
> > > diagnostic when rebuilding declaration during template instantiation if
> > > the pack was not empty.
> > >
> > > > There are no static lambdas in your examples so I'm not sure how
> > > > they're related.
> > >
> > > Sorry, I was being lazy with my examples and showing more about the
> > > capture list. Consider:
> > > ```
> > > template <typename... Types>
> > > auto func(Types... Ts) {
> > > return [Ts...] static { return 1; };
> > > }
> > >
> > > int main() {
> > > auto lambda = func();
> > > }
> > > ```
> > >
> > Like I said,
> >
> > > If the lambda-specifier-seq contains static, there shall be no
> > > lambda-capture
> >
> > `Ts...` is still a syntactic `lambda-capture`, even if it's instantiated as
> > an empty pack. I don't see how that's not a parsing error.
> Ah, I think I maybe see where the confusion is coming in, now: you think my
> example should be diagnosed and I think my example should be accepted.
>
> Based on the standards wording, I think you're right. The standard
> specifically uses "lambda-capture" as a grammar term, so it *is* a parsing
> error at that point.
>
> Based on my understanding of the intent behind the feature, I think I'm right
> and there's a core issue here. I don't think we intended to prohibit empty
> packs from being captured as non-SFINAEable error (and in off-list talks with
> @erichkeane, he agrees). as that allows different specializations of the
> function containing the lambda, which could be of use. However, I'm not 100%
> sure on the intent. CC @hubert.reinterpretcast as the C++ standards
> conformance code owner to see if he has an opinion or other recollections
> here.
I can see something like
```
[Ts...] static(sizeof...(Types) == 0) {}
```
being eventually useful, but as long as the `static` is non-conditional
allowing a capture list with an empty pack doesn't make sense to me. I think
you can always do something like
```
[]<typename = std::enable_if<sizeof...(Types) == 0>::value> {}
```
and that should have the same functionality.
Do you or Erich plan to open a CWG issue about this?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D133659/new/
https://reviews.llvm.org/D133659
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
