Move the function to get a macro name from DiagnosticRenderer.cpp to Lexer.cpp
so that other files can use it. Lexer now has two functions to get the
immediate macro name, the newly added one is better for diagnostic purposes.
Make -Wnull-conversion use this function for better NULL macro detection.
llvm-svn: 258778
Per C++14 [class.virtual]p8, it is OK for the return type's class type
to be incomplete so long as the return type is the same between the base
and complete classes.
This fixes PR26297.
llvm-svn: 258768
-Wdelete-non-virtual-dtor warns if A is a type with virtual functions but
without virtual dtor has its constructor called via `delete a`. This makes the
warning also fire if the dtor is called via `a->~A()`. This would've found a
security bug in Chromium at compile time. Fixes PR26137.
To fix the warning, add a virtual destructor, make the class final, or remove
its other virtual methods. If you want to silence the warning, there's also
a fixit that shows how:
test.cc:12:3: warning: destructor called on 'B' ... [-Wdelete-non-virtual-dtor]
b->~B();
^
test.cc:12:6: note: qualify call to silence this warning
b->~B();
^
B::
http://reviews.llvm.org/D16206
llvm-svn: 257939
This attribute may be attached to a function definition and instructs the backend to generate appropriate function entry/exit code so that
it can be used directly as an interrupt handler.
The IRET instruction, instead of the RET instruction, is used to return from interrupt or exception handlers. All registers, except for the EFLAGS register which is restored by the IRET instruction, are preserved by the compiler.
Any interruptible-without-stack-switch code must be compiled with -mno-red-zone since interrupt handlers can and will, because of the hardware design, touch
the red zone.
interrupt handler must be declared with a mandatory pointer argument:
struct interrupt_frame;
__attribute__ ((interrupt))
void f (struct interrupt_frame *frame) {
...
}
and user must properly define the structure the pointer pointing to.
exception handler:
The exception handler is very similar to the interrupt handler with a different mandatory function signature:
#ifdef __x86_64__
typedef unsigned long long int uword_t;
#else
typedef unsigned int uword_t;
#endif
struct interrupt_frame;
__attribute__ ((interrupt))
void f (struct interrupt_frame *frame, uword_t error_code) {
...
}
and compiler pops the error code off stack before the IRET instruction.
The exception handler should only be used for exceptions which push an error code and all other exceptions must use the interrupt handler.
The system will crash if the wrong handler is used.
Differential Revision: http://reviews.llvm.org/D15709
llvm-svn: 257867
-Wnull-conversion warning.
These functions are basically equivalent to other pointer returning fuctions
which are already excluded by -Wnull-conversion.
llvm-svn: 257231
Given an expression like `(&Foo)();`, we perform overload resolution as
if we are calling `Foo` directly. This causes problems if `Foo` is a
function that can't have its address taken. This patch teaches overload
resolution to ignore functions that can't have their address taken in
such cases.
Differential Revision: http://reviews.llvm.org/D15590
llvm-svn: 257016
By storing the instantiated expression back in the ParmVarDecl,
we remove the last need for separately storing the sub-expression
of a CXXDefaultArgExpr. This makes PCH/Modules merging quite
simple: CXXDefaultArgExpr records are serialized as references
to the ParmVarDecl, and we ignore redundant attempts to overwrite
the instantiated expression.
This has some extremely marginal impact on user-facing semantics.
However, the major effect is that it avoids IRGen errors about
conflicting definitions due to lambdas in the argument being
instantiated multiple times while sharing the same mangling.
It should also slightly improve memory usage and module file size.
rdar://23810407
llvm-svn: 256983
When the condition in an if statement, while statement, or for loop is created
during template instantiation, it calls MakeFullExpr with only the condition
expression. However, when these conditions are created for non-templated
code in the Parser, an additional SourceLocation is passed to MakeFullExpr.
The impact of this was that non-dependent templated code could produce
diagnostics that the same code outside templates would not. Adding the missing
SourceLocation makes diagnostics consistent between templated and non-templated
code.
llvm-svn: 256976
Summary:
There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings.
There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those.
Reviewers: joerg, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D15849
llvm-svn: 256704
The MS ABI emits a special default constructor closure thunk if a
default constructor has a weird calling convention or default arguments.
The MS ABI has a quirk: there can be only one such thunk because the
mangling scheme does not have room for distinct manglings. We must
raise a diagnostic in this eventuality.
N.B. MSVC sorta gets this right. Multiple default constructors result
in the default constructor closure getting emitted but they seem to
get confused by which default constructors are reasonable to reference
from the closure. We try to be a little more careful which results in
mild differences in behavior.
llvm-svn: 256661
declaration. This fixes an issue where we would reject (due to a claimed
ambiguity) a case where lookup finds multiple NamespaceAliasDecls from
different scopes that nominate the same namespace.
The C++ standard doesn't make it clear that such a case is in fact valid (which
I'm working on fixing), but there are no relevant rules that distinguish using
declarations and namespace alias declarations here, so it makes sense to treat
them the same way.
llvm-svn: 256601
underlying decls. Preserve the found declaration throughout, and only map to
the underlying declaration when we want to check whether it's the right kind.
This allows us to provide the right source location for the found declaration,
and prepares for the possibility of underlying decls with a different name
from the found decl.
llvm-svn: 256575
This patch fixes PR16677. The latter represents the case when due to
misprinted character class definition occurs in the scope of template
arguments. Base class of this class depends on the template parameter in the
same scope and cannot be resolved, it causes crash. Right behavior is to
make semantic processing even if the definition is wrong, as the code
that emits appropriate message is called after the processing.
llvm-svn: 256511
Given the following code:
int *_Nullable ptr;
int *_Nonnull nn = ptr;
...In C, clang will warn you about `nn = ptr`, because you're assigning
a nonnull pointer to a nullable pointer. In C++, clang issues no such
warning. This patch helps ensure that clang doesn't ever miss an
opportunity to complain about C++ code.
N.B. Though this patch has a differential revision link, the actual
review took place over email.
Differential Revision: http://reviews.llvm.org/D14938
llvm-svn: 255556
All problems described in http://llvm.org/PR25636 are implemented except for return value of the 'put' property. This patch fixes this problem with the indexed properties
Differential Revision: http://reviews.llvm.org/D15174
llvm-svn: 255218
This is the 5th Lit test patch.
Expanded expected diagnostics to vary by C++ dialect.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 255196
variables in C, in the cases where we can constant-fold it to a value
regardless (such as floating-point division by zero and signed integer
overflow). Strictly enforcing this rule breaks too much code.
llvm-svn: 254992
https://llvm.org/bugs/show_bug.cgi?id=20334
Unfortunately, clang currently checks for a certain brokenness of implementations of std::initializer_list in CodeGen (void
AggExprEmitter::VisitCXXStdInitializerListExpr), not in SemaInit. Until that is fixed, make sure we don't let broken attempts that are aggregates leak through into sema, which allows maintenance of expected invariants, and avoids triggering an assertion.
llvm-svn: 254889
to treat as an ICE results in undefined behavior. Instead, return the "natural"
result of the operation (signed wraparound / inf / nan).
llvm-svn: 254699
do scope-based lookup when looking for redeclarations of them. Add some related
missing checks for the scope-based redeclaration lookup: properly filter the
list of found declarations to match the scope, and diagnose shadowing of a
template parameter name.
llvm-svn: 254663
The tests were failing because the types of some member functions, when
printed, unexpectedly had "__attribute__((thiscall))" at the end. The
types in question were relatively unimportant to begin with, so they
were removed/replaced with regexes.
llvm-svn: 254650
The introduction of pass_object_size fixed a few bugs related to taking
the address of a function with enable_if attributes. This patch adds
tests for the cases that were fixed.
llvm-svn: 254646
These additions were meant to go in as a part of r254554; while it's
certainly nice to have new functionality, it's nicer if we have tests to
go with it. :)
llvm-svn: 254632
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.
This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.
This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:
float f = 1e100;
are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.
llvm-svn: 254574
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
llvm-svn: 254554
Function types can be extracted from member pointer types.
However, the type is not appropriate without first adjusting the calling
convention.
This fixes PR25661.
llvm-svn: 254323
We will still allow it in system headers, in macros from system headers, when
combined with an 'asm' label, and under the flag -Wno-register.
llvm-svn: 254097
MSVC supports 'property' attribute and allows to apply it to the declaration of an empty array in a class or structure definition.
For example:
```
__declspec(property(get=GetX, put=PutX)) int x[];
```
The above statement indicates that x[] can be used with one or more array indices. In this case, i=p->x[a][b] will be turned into i=p->GetX(a, b), and p->x[a][b] = i will be turned into p->PutX(a, b, i);
Differential Revision: http://reviews.llvm.org/D13336
llvm-svn: 254067
This patch adds support of #pragma vtordisp inside functions in attempt to improve compatibility. Microsoft compiler appears to save the stack of vtordisp modes on entry of struct methods' bodies and restore it on exit (method-local vtordisp).
Differential Revision: http://reviews.llvm.org/D14467
llvm-svn: 253650
is_empty, is_polymorphic, and is_abstract didn't handle incomplete types
correctly. Only non-union class types must be complete for these
traits.
is_final and is_sealed don't care about the particular spelling of the
FinalAttr.
is_interface_class should always return false regardless of its input.
The type trait can only be satisfied in a mode we do not support (/CLR).
llvm-svn: 253184
The ``disable_tail_calls`` attribute instructs the backend to not
perform tail call optimization inside the marked function.
For example,
int callee(int);
int foo(int a) __attribute__((disable_tail_calls)) {
return callee(a); // This call is not tail-call optimized.
}
Note that this attribute is different from 'not_tail_called', which
prevents tail-call optimization to the marked function.
rdar://problem/8973573
Differential Revision: http://reviews.llvm.org/D12547
llvm-svn: 252986
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.
In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.
This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).
llvm-svn: 252688
The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.
This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.
Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
llvm-svn: 252648
This attribute is used to prevent tail-call optimizations to the marked
function. For example, in the following piece of code, foo1 will not be
tail-call optimized:
int __attribute__((not_tail_called)) foo1(int);
int foo2(int a) {
return foo1(a); // Tail-call optimization is not performed.
}
The attribute has effect only on statically bound calls. It has no
effect on indirect calls. Also, virtual functions and objective-c
methods cannot be marked as 'not_tail_called'.
rdar://problem/22667622
Differential Revision: http://reviews.llvm.org/D12922
llvm-svn: 252369
This new builtin template allows for incredibly fast instantiations of
templates like std::integer_sequence.
Performance numbers follow:
My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz.
__make_integer_seq<std::integer_sequence, int, 90000> takes 0.25
seconds.
std::make_integer_sequence<int, 90000> takes unbound time, it is still
running. Clang is consuming gigabytes of memory.
Differential Revision: http://reviews.llvm.org/D13786
llvm-svn: 252036
particular don't assume that two declarations of the same kind in the same
context are declaring the same entity. That's not true when the same name is
declared multiple times as internal-linkage symbols within a module.
(getCanonicalDecl is cheap now, so we can just use it here.)
llvm-svn: 251898
We permit implicit conversion from pointer-to-function to
pointer-to-object when -fms-extensions is specified. This is rather
unfortunate, move this into -fms-compatibility and only permit it within
system headers unless -Wno-error=microsoft-cast is specified.
llvm-svn: 251738
Handle blocks in the tree transform for the typo correction as otherwise, the
capture may miss. This would trigger an assertion. Thanks to Doug Gregor for
the help with this!
Fixes PR25001.
llvm-svn: 251729
Summary:
In `MismatchingNewDeleteDetector::analyzeInClassInitializer`, if
`Field`'s initializer expression is null, lookup the field in
implicit instantiation, and use found field's the initializer.
Reviewers: rsmith, rtrieu
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9898
llvm-svn: 251335
Microsoft's ATL headers make use of this MSVC extension, add support for
it and issue a diagnostic under -Wmicrosoft-exception-spec.
This fixes PR25265.
llvm-svn: 250854
Clang will now accept this valid C++11 code:
struct A { int field; };
struct B : A {
using A::field;
enum { TheSize = sizeof(field) };
};
Previously we would classify the 'field' reference as something other
than a field, and then forget to apply the C++11 rule to allow
non-static data member references in unevaluated contexts.
This usually arises in class templates that want to reference fields of
a dependent base in an unevaluated context outside of an instance
method. Such contexts do not allow references to 'this', so the only way
to access the field is with a using decl and an implicit member
reference.
llvm-svn: 250839
This reverts commit r250592.
It has issues around unevaluated contexts, like this:
template <class T> struct A { T i; };
template <class T>
struct B : A<T> {
using A<T>::i;
typedef decltype(i) U;
};
template struct B<int>;
llvm-svn: 250774
During the initial template parse for this code, 'member' is unresolved
and we don't know anything about it:
struct A { int member };
template <typename T>
struct B : public T {
using T::member;
static void f() {
(void)member; // Could be static or non-static.
}
};
template class B<A>;
The pattern declaration contains an UnresolvedLookupExpr rather than an
UnresolvedMemberExpr because `f` is static, and `member` should never be
a field. However, if the code is invalid, it may become a field, in
which case we should diagnose it.
Reviewers: rjmccall, rsmith
Differential Revision: http://reviews.llvm.org/D6700
llvm-svn: 250592
Previously, our logic when taking the address of an overloaded function
would not consider enable_if attributes, so long as all of the enable_if
conditions on a given candidate were true. So, two functions with
identical signatures (one with enable_if attributes, the other without),
would be considered equally good overloads. If we were calling the
function instead of taking its address, then the function with enable_if
attributes would be preferred.
This patch makes us prefer the candidate with enable_if regardless of if
we're calling or taking the address of an overloaded function.
Differential Revision: http://reviews.llvm.org/D13795
llvm-svn: 250486
This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:
int foo(int a) __attribute__((enable_if(a > 0, "")));
int (*p)(int) = &foo;
int result = p(-1); // compilation succeeds; calls foo(-1)
Overloading logic has been updated to reflect this change, as well.
Functions with enable_if attributes that are always true are still
allowed to have their address taken.
Differential Revision: http://reviews.llvm.org/D13607
llvm-svn: 250090
Fixed a bug where we'd emit multiple diagnostics if there was a problem
taking the address of an overloaded template function.
Differential Revision: http://reviews.llvm.org/D13664
llvm-svn: 250078
Our self hosting buildbots found a few more tests which weren't updated
to reflect that the enum semantics are part of the Microsoft ABI.
llvm-svn: 249670
the "" and the suffix; that breaks names such as 'operator""if'. For symmetry,
also remove the space between the 'operator' and the '""'.
llvm-svn: 249641
With -fms-extensions it is possible to have a non-class record that is a
template specialization cause an assertion failure via the call to
Type::getAsCXXRecordDecl. Fixes PR 24246.
llvm-svn: 249090
specification) to an error. No compiler other than Clang seems to allow this,
and it doesn't seem like a useful thing to accept as an extension in general.
The current behavior was added for PR5957, where the problem was specifically
related to mismatches of the exception specification on the implicitly-declared
global operator new and delete. To retain that workaround, we downgrade the
error to an ExtWarn when the declaration is of a replaceable global allocation
function.
Now that this is an error, stop trying (and failing) to recover from a missing
computed noexcept specification. That recovery didn't work, and led to crashes
in code like the added testcase.
llvm-svn: 248867
This patch fixes the order in which we evaluate the different ways that
a function call could be disallowed. Now, if you call a non-overloaded
function with an incomplete type and failing enable_if, we'll prioritize
reporting the more obvious error (use of incomplete type) over reporting
the failing enable_if.
Thanks to Ettore Speziale for the patch!
llvm-svn: 248595
someone thought all the bits would be value bits in this case.
Also fix the wording of the warning -- it claimed that the width of 'bool' is
8, which is not correct; the width is 1 bit, whereas the size is 8 bits in our
implementation.
llvm-svn: 248435
We took both source locations from the end of the initializer list what
the code below doesn't expect. This can lead to a crash when rendering
the diagnostic (PR24816). Assert that we have more than one element in
a scalar initializer with too many elements.
llvm-svn: 248391
Overwide bool bitfields have eight bits of storage size, make sure we
take the padding into account when determining whether or not they are
problematic.
llvm-svn: 247651
MS compiler ignores calling convention modifiers for structors. This patch makes
clang do the same (for MS ABI). This fixes PR24595 and makes vswriter.h header
(from Windows SDK 8.1) compilable.
Differential Revision: http://reviews.llvm.org/D12402
llvm-svn: 247619
They might technically have external linkage, but it still doesn't make sense
for the user to try and export such variables. This matches MSVC's and MinGW's
behaviour.
llvm-svn: 246864
This patch does two things:
1) Don't error about dllimport/export on thread-local static local variables.
We put those attributes on static locals in dllimport/export functions
implicitly in case the function gets inlined. Now, for TLS variables this
is a problem because we can't import such variables, but it's a benign
problem becase:
2) Make sure we never inline a dllimport function TLS static locals. In fact,
never inline a dllimport function that references a non-imported function
or variable (because these are not defined in the importing library). This
seems to match MSVC's behaviour.
Differential Revision: http://reviews.llvm.org/D12422
llvm-svn: 246338
We tried to provide a very nice diagnostic when diagnosing an assignment
to a const int & produced by a function call. However, we cannot always
determine what function was called.
This fixes PR24568.
llvm-svn: 246014
Summary:
- Store the exception specification range's begin and end SourceLocation in DeclaratorChuck::FunctionTypeInfo. These SourceLocations can be used in a FixItHint Range.
- Add diagnostic; function concept having an exception specification.
Reviewers: hubert.reinterpretcast, fraggamuffin, faisalv, aaron.ballman, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11789
llvm-svn: 246005
GNU attributes can have a leading and trailing __ appended/prepended to
the attribute name. While the parser and AttributeList::getKind did the
right thing, AttributeList::getAttributeSpellingListIndex did not.
This fixes PR24565.
llvm-svn: 245953
While working around a bug in certain standard library implementations,
we would try to diagnose the issue so that library implementors would
fix their code. However, we assumed an entity being initialized was
a non-static data member subobject when other circumstances are
possible.
This fixes PR24526.
llvm-svn: 245675
Summary: Adding check to emit diagnostic for invalid tag when concept is specified and associated tests.
Reviewers: rsmith, hubert.reinterpretcast, fraggamuffin, faisalv, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D11916
llvm-svn: 245123
This non-conforming extension was introduced to make it possible for us
to correctly compile <atomic> in VS 2013 and 2015. Let's limit its
impact to system headers to encourage portable code.
llvm-svn: 244650
Our implementations of these type trait intrinsics simply mapped them to
__has_trivial_destructor. Instead, flesh these intrinsics out with a
full implementation which matches the standard's description.
llvm-svn: 244564
It's not valid code (maybe it can be made valid, but I'm not sure how).
To trigger the crash fixed in r243987 requires a friend function with
more than four template parameter lists. With this test we have at least
some coverage.
llvm-svn: 243989
Summary: Add IsConcept bit to VarDecl::NonParmVarDeclBitfields and associated isConcept/setConcept member functions. Set IsConcept to true when 'concept' specifier is in variable declaration. Create diagnostic when variable concept is not initialized.
Reviewers: fraggamuffin, hubert.reinterpretcast, faisalv, aaron.ballman, rsmith
Subscribers: aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D11600
llvm-svn: 243876
Without DR1579 implemented, the only case for -Wredundant-move is for a
parameter being returned with the same type as the function return type. Also
include a check to verify that the move constructor will be used by matching
nodes in the AST dump.
llvm-svn: 243594
Dependent types can throw off the analysis for these warnings, possibly giving
conflicting warnings and fix-its. Disabling the warning in template
instantiations will prevent this problem, and will still catch the
non-dependent cases in templates.
llvm-svn: 243538
error.
If the object being moved has a move constructor and a deleted copy constructor,
std::move is required, otherwise Clang will give a deleted constructor error.
llvm-svn: 243463
(Keep -Wmsvc-include around as an alias.)
While here, also replace the one other mention of "MSVC" in diagnostics with
"Microsoft", for consistency.
llvm-svn: 243444
There is currently no support in MSVC for using i128 as an integer
literal suffix. In fact, there appears to be no evidence that they have
ever supported this feature in any of their compilers. This was an over
generalization of their actual feature and is a nasty source of bugs.
Why is it a source of bugs? Because most code in clang expects that
evaluation of an integer constant expression won't give them something
that 'long long' can't represent. Instead of providing a meaningful
feature, i128 gives us cute ways of exploding the compiler.
llvm-svn: 243243
We treated DependentSizedArrayTypes with the same element type but
differing size expressions as equivalently canonical. This would lead
to bizarre behavior during template instantiation.
This fixes PR24212.
llvm-svn: 243093
to consider the storage size of the vector instead of its
sizeof. In other words, ban <3 x int> to <4 x int> casts,
which produced invalid IR anyway.
Also, attempt to be a little more rigorous, or at least
explicit, about when enums are allowed in these casts.
rdar://21901132
llvm-svn: 243069
MSVC 2013 ships, as part of its STL implementation, a class named
'_Atomic'. This is unfortunate because this keyword is in conflict with
the C11 keyword with the same name. Our solution was to disable this
keyword when targeting MSVC 2013 and reenable it for 2015.
However, this makes it impossible for clang's headers to make use of
_Atomic. This is problematic in the case of libc++ as it makes heavy
use of this keyword.
Let the keywordness of _Atomic float under certain circumstances:
the body of a class named _Atomic, or a class with a base specifier
named _Atomic, will not have the keyword variant of _Atomic for the
duration of the class body. This is sufficient to allow us to correctly
handle _Atomic in the STL while permitting us to use _Atomic as a
keyword everywhere else.
Differential Revision: http://reviews.llvm.org/D11233
llvm-svn: 242970
Summary:
Create diagnostic for function concept declaration which is not a
definition.
Create diagnostic for concept declaration which isn't in namespace
scope.
Create associated tests.
Reviewers: rsmith, faisalv, fraggamuffin, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11027
Patch by Nathan Wilson!
llvm-svn: 242899
Before we skipped that for virtual functions not fully qualified (r81507).
This commit basically reverts this to the older behaviour, which seems
more consistent. We now also correctly consider ill-formed calls to deleted
member functions, which were silently passed before in some cases.
The review contains the whole discussion.
PR: 20268
Differential Revision: http://reviews.llvm.org/D11334
llvm-svn: 242857
Clang used to silently ignore __declspec(novtable). It is implemented
now, but leaving the vtable uninitialized does not work when using the
Itanium ABI, where the class layout for complex class hierarchies is
stored in the vtable. It might be possible to honor the novtable
attribute in some simple cases and either report an error or ignore
it in more complex situations, but it’s not clear if that would be
worthwhile. There is also value in having a simple and predictable
behavior, so this changes clang to simply ignore novtable when not using
the Microsoft C++ ABI.
llvm-svn: 242730
If we're returning a function parameter, copy elision isn't possible,
so we now warn for redundant move.
PR: 23819
Differential Revision: http://reviews.llvm.org/D11305
llvm-svn: 242600
-fapple-kext is an exception because calls will still go through
the vtable in that mode. Add a note to make the user aware of that.
PR: 23215
Differential Revision: http://reviews.llvm.org/D10935
llvm-svn: 242246
We referred to all declaration in definitions in our diagnostic messages
which is can be inaccurate. Instead, classify the declaration and emit
an appropriate diagnostic for the new declaration and an appropriate
note pointing to the old one.
This fixes PR24116.
llvm-svn: 242190
If a lambda used as default argument in a method declaration contained
a local class, that class was incorrectly recognized as nested class.
In this case compiler tried to postpone parsing of this class until
the enclosing class is finished, which caused crashes in some cases.
This change fixes PR13987.
Differential Revision: http://reviews.llvm.org/D11006
llvm-svn: 242132
In the test, y1 is not reference compatible to y2 and we currently assume
the cast is ill-formed so we emit a diagnostic. Instead, in order to honour
the standard, if y1 it's not reference-compatible to y2 then it can't be
converted using a static_cast, and a reinterpret_cast should be tried instead.
Richard Smith provided the correct interpretation of the standard and
explanation about the subtle difference between "can't be cast" and "the cast
is ill-formed". The former applies in this case.
PR: 23802
llvm-svn: 241998
an existing using shadow declaration if they define entities of the same kind
in different namespaces.
We'd previously check this consistently if the using-declaration came after the
other declaration, but not if it came before.
llvm-svn: 241428
This patch fixes a crash caused by the following case:
template<typename T>
auto f(T x) {
auto g = [](auto ... args) {
auto h = [args...]() -> int {
return 0;
};
return h;
};
return g;
}
auto x = f(0)();
When the templated function 'f' is instantiated and the inner-most
lambda is transformed the ellipsis location on the captured variable
is lost. Then the lambda returned by 'f' is instantiated and the
tree transformer chokes on the invalid ellipsis location. The
problem is fixed by making a minor change to properly track the
ellipsis location.
This fixes PR23716.
Differential Revision: http://reviews.llvm.org/D10590
llvm-svn: 240740
In certain cases, the tree transform would introduce new TypoExprs while
trying one of the corrections, invalidating the unique_ptr in the state
reference, and also causing a TypoExpr to exist that will never be
corrected since it doesn't exist in the final corrected expression. The
simple solution to both problems is to temporarily disable typo
correction while handling potentially ambiguous typo corrections.
llvm-svn: 240734
Summary:
This patch reduces duplication in the template argument deduction code
for handling deduction from initializer lists in a function call. This
extends the fix for PR12119 to also apply to the case where the
corresponding parameter is a trailing parameter pack.
Test Plan:
A test for deduction from nested initializer lists where the
corresponding parameter is a trailing parameter pack is added in
`clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp`.
Reviewers: fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10681
llvm-svn: 240612
Addresses a conflict with glibc's __nonnull macro by renaming the type
nullability qualifiers as follows:
__nonnull -> _Nonnull
__nullable -> _Nullable
__null_unspecified -> _Null_unspecified
This is the major part of rdar://problem/21530726, but does not yet
provide the Darwin-specific behavior for the old names.
llvm-svn: 240596
This generalizes the checking of null arguments to also work with
values of pointer-to-function, reference-to-function, and block
pointer type, using the nullability information within the underling
function prototype to extend non-null checking, and diagnoses returns
of 'nil' within a function with a __nonnull return type.
Note that we don't warn about nil returns from Objective-C methods,
because it's common for Objective-C methods to mimic the nil-swallowing
behavior of the receiver by checking ostensibly non-null parameters
and returning nil from otherwise non-null methods in that
case.
It also diagnoses (via a separate flag) conversions from nullable to
nonnull pointers. It's a separate flag because this warning can be noisy.
llvm-svn: 240153
Introduces the type specifiers __nonnull, __nullable, and
__null_unspecified that describe the nullability of the pointer type
to which the specifier appertains. Nullability type specifiers improve
on the existing nonnull attributes in a few ways:
- They apply to types, so one can represent a pointer to a non-null
pointer, use them in function pointer types, etc.
- As type specifiers, they are syntactically more lightweight than
__attribute__s or [[attribute]]s.
- They can express both the notion of 'should never be null' and
also 'it makes sense for this to be null', and therefore can more
easily catch errors of omission where one forgot to annotate the
nullability of a particular pointer (this will come in a subsequent
patch).
Nullability type specifiers are maintained as type sugar, and
therefore have no effect on mangling, encoding, overloading,
etc. Nonetheless, they will be used for warnings about, e.g., passing
'null' to a method that does not accept it.
This is the C/C++ part of rdar://problem/18868820.
llvm-svn: 240146
If definition of a class is unknown and out-of-line definition of its
member is encountered, do not parse the member declaration.
This change fixes PR18542.
Differential Revision: http://reviews.llvm.org/D8010
llvm-svn: 239483
Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm
This patch attempts to fix this problem.
Given the following code snippet,
struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };
struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };
Differential Review: http://reviews.llvm.org/D5789
llvm-svn: 239446
The machinery added to permit a static_cast from void-ptr to fn-ptr
unintentionally gets triggered for c-style casts and function-style
casts. The observable effect was a diagnostic issued inappropriately.
llvm-svn: 239382
It is safe to add a dll attribute if the base class template previously only had
an explicit instantiation declaration, or was implicitly instantiated.
I both those cases, the members would not have been codegenned yet. In the case
of explicit instantiation declaration this is natural, and for implicit
instantiations, codegen is deferred (see r225570).
This is work towards fixing PR23770.
llvm-svn: 239373
Don't warn about not being able to propagate dll attribute to a base class template
when that base already has a different attribute.
MSVC doesn't actually try to do this; the first attribute that was propagated
takes precedence, so Clang is already doing the right thing and there's no
need to warn.
(This is a step towards fixing PR21718.)
llvm-svn: 239372
It's better not to rely on the diagnostics engine to pretty print the
argument to decltype. Instead, exercise the functionality in
DeclPrinterTest.
llvm-svn: 239197
We would crash in the DeclPrinter trying to pretty-print the
static_assert message. C++1z-style assertions don't have a message so
we would crash.
This fixes PR23756.
llvm-svn: 239170
The MSVC 2013 and 2015 implementation of std::atomic is specialized for
pointer types. The member functions are implemented using a static_cast
from void-ptr to function-ptr which is not allowed in the standard.
Permit this conversion if -fms-compatibility is present.
This fixes PR23733.
llvm-svn: 238877
this fixes http://llvm.org/PR17424
fillAttributedTypeLoc() function is only called with AttributeLists of either
DeclarationChunk (which is used for each type in a declarator being parsed) or
DeclSpec (which captures information about declaration specifiers).
As C++11 attributes actually appertain to declarators, they are moved straight
to the declarator’s attr list in distributeFunctionTypeAttrFromDeclSpec()
function.
'Put them wherever you like' semantics is not supported for C++11 attributes
(but is allowed for GNU attributes, for example). So when we meet an attribute
while parsing the declaration, we cannot be sure if it appertains to either
DeclarationChunk or DeclSpec.
This investigation correlates with the history of changes of SemaType.cpp:
• Asserts in fillAttributedTypeLoc() were added on 3 Mar 2011 in r126986
(http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
20110228/039638.html);
• Distributing C++11 attrs to the declarator was added on 14 Jan 2013
in r172504 (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
20130114/071830.html).
Considering all written above I changed asserts in fillAttributedTypeLoc()
to nullptr checks.
This fixes PR17424 and related assertion on
[[gnu::fastcall]] void __stdcall foo();
Author: Alexey Frolov
Differential Revision: http://reviews.llvm.org/D9288
llvm-svn: 238550
When checking if a function is noreturn, consider a codepath to be noreturn if
the path destroys a class and the class destructor, base class destructors, or
member field destructors are marked noreturn.
Differential Revision: http://reviews.llvm.org/D9454
llvm-svn: 238382
Note: __declspec is also temporarily enabled when compiling for a CUDA target because there are implementation details relying on __declspec(property) support currently. When those details change, __declspec should be disabled for CUDA targets.
llvm-svn: 238238
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
rev 2 update:
`getNewExprFromInitListOrExpr` should return `dyn_cast_or_null`
instead of `dyn_cast`, since `E` might be null.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237608
The error has the form ... 'int' ... 'const int' ... dropped qualifiers. At
first glance, it appears that the const qualifier is added. Reverse the types
so that the second type is less qualified than the first.
llvm-svn: 237482
This reverts commit 742dc9b6c9686ab52860b7da39c3a126d8a97fbc.
This is generating multiple segfaults in our internal builds.
Test case coming up shortly.
llvm-svn: 237391
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237368
A LambdaCapture does not have sufficient information
to correctly determine whether it is an init-capture or not.
Doing so requires knowledge held in the LambdaExpr itself.
It the case of a nested capture of an init-capture it is not
sufficient to check (as LambdaCapture::isInitCapture did)
whether the associated VarDecl was from an init-capture.
This patch moves isInitCapture to LambdaExpr and updates
Capture->isInitCapture() to Lambda->isInitCapture(Capture).
llvm-svn: 236760
This is needed to prevent a TypoExpr from being corrected to a variable
when the TypoExpr is a subexpression of that variable's initializer.
Also exclude more keywords from the correction candidate pool when the
subsequent token is .* or ->* since keywords like "new" or "return"
aren't valid on the left side of those operators.
Fixes PR23140.
llvm-svn: 236519
The LHS was already being corrected before being set to ExprError when
the RHS is invalid, but when it was present the middle of a ternary
expression would be dropped in the error paths.
Fixes PR23350.
llvm-svn: 236347
-Wpessimizing-move warns when a call to std::move would prevent copy elision
if the argument was not wrapped in a call. This happens when moving a local
variable in a return statement when the variable is the same type as the
return type or using a move to create a new object from a temporary object.
-Wredundant-move warns when an implicit move would already be made, so the
std::move call is not needed, such as when moving a local variable in a return
that is different from the return type.
Differential Revision: http://reviews.llvm.org/D7633
llvm-svn: 236075
Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the point where we detected that a variable
needed to be captured. This was wrong in a number of subtle ways. In
PR23334, we couldn't correctly handle the list of potential odr-uses
resulting from the capture, and our attempt to recover from that resulted
in a use-after-free.
We now defer building the initialization expression until we leave the lambda
body and return to the enclosing context, where the initialization does the
right thing. This patch only covers lambda-expressions, but we should apply
the same change to blocks and captured statements too.
llvm-svn: 235921
We could probably make this work if we cared enough. However, we are
far outside any language rules at this point.
This fixes PR21834.
llvm-svn: 235818
For example, a function taking a parameter with internal linkage will
itself have internal linkage since it cannot be called outside the
translation unit.
Differential Revision: http://reviews.llvm.org/D9182
llvm-svn: 235471
(For example needed to parse system header inputscope.h, which first has
an extern "C" selectany IID and then later an extern "C" declaration of that
same IID.)
llvm-svn: 235174
r235046 turned "extern __declspec(selectany) int a;" from a declaration into
a definition to fix PR23242 (required for compatibility with mc.exe output).
However, this broke parsing Windows headers: A d3d11 headers contain something
like
struct SomeStruct {};
extern const __declspec(selectany) SomeStruct some_struct;
This is now a definition, and const objects either need an explicit default
ctor or an initializer so this errors out with
d3d11.h(1065,48) :
error: default initialization of an object of const type
'const CD3D11_DEFAULT' without a user-provided default constructor
(cl.exe just doesn't implement this rule, independent of selectany.)
To work around this, weaken this error into a warning for selectany decls
in microsoft mode, and recover with zero-initialization.
Doing this is a bit hairy since it adds a fixit on an error emitted
by InitializationSequence – this means it needs to build a correct AST, which
in turn means InitializationSequence::Failed() cannot return true when this
fixit is applied. As a workaround, the patch adds a fixit member to
InitializationSequence, and InitializationSequence::Perform() prints the
diagnostic if the fixit member is set right after its call to Diagnose.
That function is usually called when InitializationSequences are used –
InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker
case never performs default-initialization, so this is technically OK.
This is the alternative, original fix for PR20208 that got reviewed in the
thread "[patch] Improve diagnostic on default-initializing const variables
(PR20208)". This change basically reverts r213725, adds the original fix for
PR20208, and makes the error a warning in Microsoft mode.
llvm-svn: 235166
-Wrange-loop-analysis is a subgroup of -Wloop-analysis and will warn when
a range-based for-loop makes copies of the elements in the range. If possible,
suggest the proper type to prevent copies, or the non-reference to help
distinguish copy versus non-copy forms. Existing warnings in -Wloop-analysis
are moved to -Wfor-loop-analysis, also a subgroup of -Wloop-analysis.
Differential Revision: http://reviews.llvm.org/D4169
llvm-svn: 234804
Previously, many error messages would simply be "read-only variable is not
assignable" This change provides more information about why the variable is
not assignable, as well as note to where the const is located.
Differential Revision: http://reviews.llvm.org/D4479
llvm-svn: 234677
Take advantage of the delayed typo no longer being eagerly corrected to
a keyword to filter out keyword corrections (and other things like
unresolved & overloaded expressions, which have placeholder types) when
correcting typos inside of a decltype().
llvm-svn: 234623
Given something like 'int({}, 1)', we would try to emit a diagnostic
regarding the excess element in the scalar initializer. However, we
assumed that the initializer list had an element in it.
llvm-svn: 234565
A [*] is only allowed in a declaration for a function, not in its
definition. We didn't correctly recurse on reference types while
looking for it, causing us to crash in CodeGen instead of rejecting it.
llvm-svn: 234528
The previous implementation would copy the attribute from the class to
functions that have the class as their return type when the functions
are first declared. This proved to have two flaws:
1) if the class is forward-declared without the attribute and a
function or method with the class as a its return type is declared,
and afterward the class is defined with warn_unused_result, the
function or method would never inherit the attribute, and
2) the check simply failed for functions and methods that are part of
a template instantiation, regardless of whether the class with
warn_unused_result is part of a specific instantiation or part of
the template itself (presumably because those function/method
declaration does not hit the same code path as a non-template one
and so never inherits the attribute).
The new approach is to instead modify the two places where a function or
method call is checked for the warn_unused_result attribute on the decl
by extending the checks to also look for the attribute on the decl's
return type.
Additionally, the check for return types that have the warn_unused_result
now excludes pointers and references to such types, as such return types do
not necessarily imply a transfer of ownership for the underlying object
being referred to by the return value. This does not change the behavior
of functions that are directly given the warn_unused_result attribute.
llvm-svn: 234526
A dependent alignment attribute (like __attribute__((aligned(...))) or
__declspec(align(...))) on a non-dependent typedef or using declaration
poses a considerable challenge: the type is _not_ dependent, the size
_may_ be dependent if the type is used as an array type, the alignment
_is_ dependent.
It is reasonable for a compiler to be able to query the size and
alignment of a complete type. Let's help that become an invariant.
This fixes PR22042.
Differential Revision: http://reviews.llvm.org/D8693
llvm-svn: 234280
StmtPrinter assumed that the first template arg was the pack and
attempted to iterate it. However, the GNU extension (which is really
just N3599), has two template arguments. In this case, the second
argument is the pack containing the string contents.
Handle this by desugaring the call to the explicit operator.
For example:
"qux" _zombocom will be shown as
operator "" _zombocom<char, 'q', 'u', 'x'>() in diagnostics and AST
dumps.
N.B. It is actually impossible to render the arguments back to the
source form without storing more information in the AST. For example,
we cannot tell if the user wrote u8"qux" or "qux". We also lose
fidelity when it comes to non-char types for this exact reason (e.g. it
is hard to render a list of wchar_t back to something that can be
printed to the screen even if you don't have to consider surrogate
pairs).
This fixes PR23120.
llvm-svn: 234110
Update the test cases to pass when lambda call operators use thiscall.
Update the lambda-to-block conversion operator to use the default free
function calling convention instead of the call operator's convention.
This reverts commit r233082 and re-instates r233023.
llvm-svn: 233835
ExpandBuiltinMacro would strip the identifier and downstream users crash
when they encounter an identifier token with nullptr identifier info.
Found by afl-fuzz.
llvm-svn: 233497
integral promotion only if it converts to the underlying type or its promoted
type, not if it converts to the promoted type that the bitfield would have it
if were of the underlying type.
llvm-svn: 233457
Previously, if the expr list parsed fine but the expr to the left of the
open parenthesis was invalid (when parsing the suffix of a
postfix-expression), the parsed expr list was just ignored.
Fixes PR23005.
llvm-svn: 233347
Construction of LocalInstantiationScope automatically updates the current scope
inside Sema. However, when cloning a scope, the current scope does not change.
Change the cloning function to preserve the current scope.
Review: http://reviews.llvm.org/D8407
BUG: https://llvm.org/bugs/show_bug.cgi?id=22931
llvm-svn: 232675
We disabled support for _Atomic because the STL had name conflicts,
they've been resolved in 2015. Similarly, reenable char16_t and
char32_t.
llvm-svn: 232611
contained a typo correction (the auto decl was being marked as dependent
unnecessarily, which triggered an assertion in cases where the size of
the type is needed).
llvm-svn: 232568
When if statement condition ended in a macro:
if (ptr == NULL);
the check used to consider the definition location of NULL, instead of the
current line.
Patch by Manasij Mukherjee.
llvm-svn: 232295
This is a bit more involved than I anticipated, so here's a breakdown
of the changes:
1. Call ActOnFinishFunctionBody _after_ we parsed =default and
=delete specifiers. Saying that we finished the body before parsing
=default is just wrong. Changing this allows us to use isDefaulted
and isDeleted on a decl in ActOnFinishFunctionBody.
2. Check for -Wmissing-prototypes after we parsed the function body.
3. Disable -Wmissing-prototypes when the Decl isDeleted.
llvm-svn: 232040
Sema overrides ASTContext's policy on the first emitted diagnostic
(doesn't matter if it's ignored or not). This means changing the order
of diagnostic emission in Sema suddenly changes the text of diagnostic
emitted from the parser.
In the test case -Wmissing-prototypes (ignored) was the culprit, use
'int main' to suppress that warning so we see when this regresses.
Also move it into Sema/ as it's not testing any C++.
llvm-svn: 232039
OpenCL C Spec v2.0 Section 6.13.11
- Made c11 _Atomic being accepted only for c11 compilations
- Implemented CL2.0 atomics by aliasing them to the corresponding c11 atomic types using implicit typedef
- Added diagnostics for atomics Khronos extension enabling
llvm-svn: 231932
This only warns on direct gotos and indirect gotos with a unique label
(`goto *&&label;`). Jumping out ith a true indirect goto is already an error.
This isn't O(1), but goto statements are less common than continue, break, and
return. Also, the GetDeepestCommonScope() call in the same function does the
same amount of work, so this isn't worse than what's there in a complexity
sense, and it should be pretty fast in practice.
This is the last piece that was missing in r231623.
llvm-svn: 231628
GCC -pedantic produces a format warning when the "%p" specifier is used with
arguments that are not void*. It's useful for portability to be able to
catch such warnings with clang as well. The warning is off by default in
both gcc and with this patch. This patch enables it either when extensions
are disabled with -pedantic, or with the specific flag -Wformat-pedantic.
The C99 and C11 specs do appear to require arguments corresponding to 'p'
specifiers to be void*: "If any argument is not the correct type for the
corresponding conversion specification, the behavior is undefined."
[7.19.6.1 p9], and of the 'p' format specifier "The argument shall be a
pointer to void." [7.19.6.1 p8]
Both printf and scanf format checking are covered.
llvm-svn: 231211
restrict is a keyword in C99 but not in C++ while clang accepts __restrict for C++ code. Modify the TypePrinter to print __restrict when not processing C99 code.
Printing restrict in C++ was problematic as printing the argument of
int f(int * __restrict a) { ... }
resulted in
int *restrict a
which is incorrect.
http://reviews.llvm.org/D8048
llvm-svn: 231179
`isTrackedVar` has been updated to also track records.
`DeclRefExpr`s appearing on the left side of a comma operator are
ignored, while those appearing on the right side are classified as
`Use`.
Patch by Enrico Pertoso.
llvm-svn: 231068
The exception object should be unqualified. Using a qualified exception
object results in the wrong copy constructor getting called when the
catch handler executes.
llvm-svn: 231054
This is only a problem in C++03 mode targeting MS ABI (MinGW doesn't
export inline methods, and C++11 marks these methods implicitly
deleted).
Since targeting the MS ABI in pre-C++11 mode is a rare configuration,
this will probably not get fixed, but we can at least have a better
error message.
llvm-svn: 230115
MinGW neither imports nor exports such methods. The import bit was
committed earlier, in r221154, and this takes care of the export part.
This also partially fixes PR22591.
llvm-svn: 229922
The motivation is to fix a crash on
struct S {} s;
Foo S::~S() { s.~S(); }
What was happening here was that S::~S() was marked as invalid since its
return type is invalid, and as a consequence CheckFunctionDeclaration() wasn't
called and S::~S() didn't get merged into S's implicit destructor. This way,
the class ended up with two destructors, which confused the overload printer
when it suddenly had to print two possible destructors for `s.~S()`.
In addition to fixing the crash, this change also seems to improve diagnostics
in a few other places, see test changes.
Crash found by SLi's bot.
llvm-svn: 229639
ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls
ActOnStartCXXMemberReference() to inform sema that a member reference is about
to start, and that function lets the parser know if sema thinks that the
base expression's type could allow a pseudo destructor from a semantic point of
view (for example, if the the base expression has a dependent type).
ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and
passes MayBePseudoDestructor on to that function, expecting the function to
set it to false if a pseudo destructor is impossible from a syntactic point of
view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier()
had early-outs for ::new and __super, so MayBePseudoDestructor stayed true,
so we tried to parse a pseudo dtor, and then became confused since we couldn't
find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets
MayBePseudoDestructor to false above the early exits.
Parts of this found by SLi's bot.
llvm-svn: 229449
The deprecated attribute was adopted as part of the C++14, however, there is a
GNU version available in C++11. When using C++ earlier than C++14, diagnose the
use of the attribute without the GNU scope, but only when using the generalised
attribute syntax.
llvm-svn: 229447
David Majnemer