The 'class' or 'struct' keyword is only permitted as part of either an
enum definition or a standalone opaque-enum-declaration, not as part of
an elaborated type specifier. We previously failed to diagnose this, and
generally didn't properly implement the restrictions on elaborated type
specifiers for enumeration types.
In passing, also fixed incorrect parsing for enum-bases, which we
previously parsed as a type-name, but are actually a type-specifier-seq.
This matters for cases like 'enum E : int *p;', which is valid as a
Microsoft extension.
Plus some minor parse diagnostic improvements.
Bumped the recently-added ExtWarn for 'enum E : int x;' to be
DefaultError; this is not an intentional extension, so producing an
error by default seems appropriate, but the warning flag to disable it
may still be useful for code written against old Clang. The same
treatment is given here to the diagnostic for 'enum class E x;', which
we similarly have incorrectly accepted for many years. These diagnostics
continue to be suppressed under -fms-extensions and when compiling
Objective-C code. We will need to decide separately whether Objective-C
should follow the C++ rules or the (older) MSVC rules.
Previously we implemented non-standard disambiguation rules to
distinguish an enum-base from a bit-field but otherwise treated a :
after an elaborated-enum-specifier as introducing an enum-base. That
misparses various examples (anywhere an elaborated-type-specifier can
appear followed by a colon, such as within a ternary operator or
_Generic).
We now implement the C++11 rules, with the old cases accepted as
extensions where that seemed reasonable. These amount to:
* an enum-base must always be accompanied by an enum definition (except
in a standalone declaration of the form 'enum E : T;')
* in a member-declaration, 'enum E :' always introduces an enum-base,
never a bit-field
* in a type-specifier (or similar context), 'enum E :' is not
permitted; the colon means whatever else it would mean in that
context.
Fixed underlying types for enums are also permitted in Objective-C and
under MS extensions, plus as a language extension in all other modes.
The behavior in ObjC and MS extensions modes is unchanged (but the
bit-field disambiguation is a bit better); remaining language modes
follow the C++11 rules.
Fixes PR45726, PR39979, PR19810, PR44941, and most of PR24297, plus C++
core issues 1514 and 1966.
This is mostly the same as the
[[clang::require_constant_initialization]] attribute, but has a couple
of additional syntactic and semantic restrictions.
In passing, I added a warning for the attribute form being added after
we have already seen the initialization of the variable (but before we
see the definition); that case previously slipped between the cracks and
the attribute was silently ignored.
llvm-svn: 370972
When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an
extension) when we do the same for other tokens starting with a '>', we can't
just use a location pointing to the first '>' as the location of the split
token, because that would result in our miscomputing the length and spelling
for the token. As a consequence, for example, a refactoring replacing 'A<X>'
with something else would sometimes replace one character too many, and
similarly diagnostics highlighting a template-id source range would highlight
one character too many.
Fix this by creating an expansion range covering the first character of the
'>>' token, whose spelling is '>'. For this to work, we generalize the
expansion range of a macro FileID to be either a token range (the common case)
or a character range (used in this new case).
llvm-svn: 331155
We were incorrectly setting PrevTokLocation to the first token in the
annotation token instead of the last when consuming it. To fix this without
adding a complex switch to the hot path through ConsumeToken, we now have a
ConsumeAnnotationToken function for consuming annotation tokens in addition
to the other Consume*Token special case functions.
llvm-svn: 303372
This CL has caused bootstrap failures on Linux and OSX buildbots running with -Werror.
Example report from http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/13183/steps/bootstrap%20clang/logs/stdio:
================================================================
[ 91%] Building CXX object tools/clang/tools/diagtool/CMakeFiles/diagtool.dir/ShowEnabledWarnings.cpp.o
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/AMDGPUISelDAGToDAG.cpp:20:
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIISelLowering.h:19:
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIInstrInfo.h:71:8: error: 'getLdStBaseRegImmOfs' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/include/llvm/Target/TargetInstrInfo.h:815:16: note: overridden virtual function is here
virtual bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
================================================================
llvm-svn: 218969
for an overriding method if class has at least one
'override' specified on one of its methods.
Reviewed by Doug Gregor. rdar://18295240
(I have already checked in all llvm files with missing 'override'
methods and Bob Wilson has fixed a TableGen of FastISel so
no warnings are expected from build of llvm after this patch.
I have already verified this).
llvm-svn: 218925
allow this, and we should warn on it, but it turns out that people were already
relying on this.
We should introduce a -Wgcc-compat warning for this if the attributes are known
to GCC, but we don't currently track enough information about attributes to do
so reliably.
llvm-svn: 200045
member-declaration. In the process, fix a couple of bugs that had crept in
where we would parse the first and subsequent member-declarators differently
(in particular, we didn't accept an asm-label on a member function definition
within a class, and we would accept virt-specifiers and attributes in the wrong
order on the first declarator but not on subsequent ones).
llvm-svn: 199957
followed by an identifier, then diagnose an identifier as being a bogus part of
the declarator instead of tripping over it. Improves diagnostics for cases like
std::vector<const int *p> my_vec;
llvm-svn: 186061
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.
llvm-svn: 179969
scope to -Wc++11-extensions. Move extra semicolon after member function
definition diagnostic out of -pedantic, since C++ allows a single semicolon
there. Keep it in -Wextra-semi, though, since it's still questionable.
llvm-svn: 160618
being defined here: [] () -> struct S {} does not define struct S.
In passing, implement DR1318 (syntactic disambiguation of 'final').
llvm-svn: 152551
instead of a semicolon (as sometimes happens during refactorings). When such a
comma is seen at the end of a line, and is followed by something which can't
possibly be a declarator (or even something which might be a plausible typo for
a declarator), suggest that a semicolon was intended.
llvm-svn: 142544
Richard Smith