This is an archive of the discontinued LLVM Phabricator instance.

[clang] Provide a more specific diagnostic for a misplaced lambda capture-default.
ClosedPublic

Authored by riccibruno on Jul 13 2020, 6:47 AM.

Details

Summary

Currently a capture-default which is not the first element in the lambda-capture is diagnosed with a generic expected variable name or 'this' in lambda capture list, which is true but not very helpful.

If we don't have already parsed a capture-default then a lone "&" or "=" is likely to be a misplaced capture-default, so diagnose it as such.

Diff Detail

Event Timeline

riccibruno created this revision.Jul 13 2020, 6:47 AM

clang-format the tests

riccibruno retitled this revision from [clang] Diagnose a misplaced lambda capture-default. to [clang] Provide a more specific diagnostic for a misplaced lambda capture-default..

Get rid of the note which doesn't add anything.

aaron.ballman added inline comments.Jul 15 2020, 5:05 AM
clang/lib/Parse/ParseExprCXX.cpp
937

Would it make sense to provide a fix-it to move the capture default to the start of the list automatically, or is that a pain?

clang/test/Parser/lambda-misplaced-capture-default.cpp
12

Can you also add a test showing that [=, &i] continues to behave properly (to test the &] checking logic)?

clang-format again, sigh...

riccibruno marked 3 inline comments as done.

Add some tests showing that a by-ref capture is still parsed properly, including some tests with a capture containing a pack expansion.

Thanks for the additional tests. This LGTM, though I still wonder about the fix-it (not certain if you saw the comment).

riccibruno added inline comments.Jul 15 2020, 7:45 AM
clang/lib/Parse/ParseExprCXX.cpp
937

I have thought about doing that, but my understanding is that a fix-it must fix the error. But here the capture-default might conflict with one of the other captures (both before and after).

To make sure that the fix-it is safe we would have to look at the other captures (before and after). This is certainly not impossible but a bit more tricky.

aaron.ballman accepted this revision.Jul 15 2020, 8:03 AM

LGTM!

clang/lib/Parse/ParseExprCXX.cpp
937

That's a good reason to not do it right now, thanks!

This revision is now accepted and ready to land.Jul 15 2020, 8:03 AM
This revision was automatically updated to reflect the committed changes.