r291905 - [Sema] Add warning for unused lambda captures

[Nico Weber via cfe-commits]

On Sun, Jan 22, 2017 at 6:17 AM, Malcolm Parsons <malcolm.parsons at gmail.com>
wrote:

> On 20 January 2017 at 21:32, Nico Weber <thakis at chromium.org> wrote:
> > This warns about code like
> >
> >   constexpr int foo = 4;
> >   [&foo]() { use(foo); }
> >
> > That's correct, but removing &foo then makes MSVC complain about this
> code
> > like "error C3493: 'foo' cannot be implicitly captured because no default
> > capture mode has been specified". A workaround is to make foo static
> const
> > instead of constexpr.
> >
> > This seems like an MSVC bug, but it's still a bit annoying that clang now
> > suggests doing things that won't build in other compilers. Any ideas
> what to
> > do about this?
>
> Should Clang care about the behaviour of other compilers that don't
> follow the standard?
>

clang should be a compiler that people like to use. Multi-platform
development isn't super uncommon, so trying to give a good experience in
that case seems like a good thing to me -- and we've tried to do that in
the past pretty hard. It's possible that "do nothing" is the right thing,
but "well that other compiler is buggy" seems like a somewhat
oversimplified reply.


> You could:
> Disable the warning on the command line.
> Disable the warning with a pragma.
>

It's an error, not a warning.


> Cast foo to void inside the lambda.
>

That's equivalent to disabling the clang warning in those cases (which
would be a shame, since the warning is super useful, and it doesn't
introduce problems in most cases -- only with local constexprs). Maybe the
warning could be split in two, so that it can be toggled separately for
constexpr?


> Only capture foo when building with MSVC.

Stop building with MSVC.
>

This reply like this make me believe you think it was silly to even report
this problem. I don't think it's silly, and there's ample precedent in
clang to make it work well in the actual world instead of in a world we
wished we lived in.


> Complain to Microsoft.
>

Already done. The reality is that their shipping compiler produces this
diagnostic, and the current 2017 build does too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170123/953dd192/attachment-0001.html>