On Sun, Jan 22, 2017 at 6:17 AM, Malcolm Parsons <malcolm.pars...@gmail.com> wrote:
> On 20 January 2017 at 21:32, Nico Weber <tha...@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.
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits