thakis added inline comments.
================
Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+ auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed
in lambda parameter}}
+ __auto_type g = 2;
+ struct BitField { int field:2; };
----------------
comex wrote:
> thakis wrote:
> > Shouldn't this say "warning: __auto_type is a gnu extension" (since this
> > uses -std=c++14, not -std=gnu++14)?
> Hmm... when I added `ext_auto_type` to the .td, I didn't notice the
> difference between Extension and ExtWarn. Since the patch currently uses
> Extension, it won't warn by default, but will with `-pedantic`, `-Wgnu`, or
> `-Wgnu-auto-type`. The C test uses `-pedantic` so it gets the warning.
>
> Is there an explicit policy on which extensions should be ExtWarn? Looking
> at the rest of that file, ExtWarns seem to be mostly either (a) standardized
> extensions (which will warn if `-std` is too early) and (b) 'extensions' that
> are more like "Clang will accept your buggy code" than features. Most GNU
> extensions are just Extension, so I think it makes sense to do the same for
> `__auto_type`.
>
> I could update the C++ test to add `-pedantic`, but arguably it makes more
> sense to test the fact that the warning is not emitted by default.
I'm not sure either. `typeof` warns with -std=c++14 but not with -std=gnu++14.
From a user perspective, this makes sense to me: I want to write standard c++
and I want the compiler to help me with that, but I don't want to get all the
pedantic warnings that -pedantic entails. For example, consider using clang-cl
to build Windows code, and wanting MSVC to be able to build said Windows code
too. (This can of course go wrong with standard C++ too, but in that case I'm
running into MSVC bugs which will eventually be fixed.) So if it's possible to
match how typeof works, I think that'd be good. If it's not possible, this
wouldn't be the only GNU extension allowed in -std=c++14 mode though, so it's
not a big thing.
http://reviews.llvm.org/D12686
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
