| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
type. Patch by Stephan Bergmann!
llvm-svn: 225889
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the following:
void f(int x) { extern int x; }
The second declaration of 'x' shouldn't be considered a redeclaration of
the parameter.
This is a different approach to r225780.
llvm-svn: 225875
|
| |
|
|
|
|
|
|
|
|
|
|
| |
conflicting attribute, warn about the conflict and pick a "winning"
attribute to preserve, instead of emitting an error. This matches the
behavior when the conflicting attributes are on different declarations.
Along the way I discovered that conflicts involving __forceinline were
reported as 'always_inline' (alternate spelling, same attribute) so
fixed that up to report the attribute as spelled in the source.
llvm-svn: 225813
|
| |
|
|
|
|
|
| |
This reverts commit r225780, we can't compile line 181 in
sanitizer_platform_limits_posix.cc with this commit.
llvm-svn: 225781
|
| |
|
|
|
|
|
|
|
|
| |
In the following:
void f(int x) { extern int x; }
The second declaration of 'x' shouldn't be considered a redeclaration of
the parameter.
llvm-svn: 225780
|
| |
|
|
|
|
|
|
| |
We'd crash trying to make the SourceRange for the tokens we'd like to
highlight. Don't assume there is more than one token makes up the
default argument.
llvm-svn: 225774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two things in a C++ program that need to read the vtable pointer:
Constructors and destructors. (A few other operations -- virtual calls,
dynamic cast, rtti -- read the vtable pointer off a this pointer, but for
this they don't need the vtable symbol.) Implicit constructors and destructors
and explicit constructors already marked the vtable as used, but explicit
destructors didn't.
Note that the only thing sema's "mark a class's vtable used" does is to mark all
final overriders of the class as referenced, it does _not_ cause emission of
the vtable itself. This is done on demand by codegen, independent of sema,
since sema might emit functions that are not referenced. (The exception are
vtables that are forced via key functions -- these are forced onto codegen
by sema.)
This bug went unnoticed for years because it doesn't have observable effects
(yet -- I want to change this in PR20337, which is why I noticed this).
r213109 made it so that _calls_ to constructors don't mark the vtable used.
Currently, _calls_ to destructors still mark the vtable used. If that
wasn't the case, this program would tickle the problem:
test.h:
template <typename T>
struct B {
int* p;
virtual ~B() { delete p; }
virtual void f() {}
};
struct __attribute__((visibility("default"))) C {
C();
B<int> m;
};
test2.cc:
#include "test.h"
int main() {
C* c = new C;
delete c;
}
test3.cc:
#include "test.h"
C::C() {}
# This bin/clang++ binary doesn't MarkVTableUsed() for virtual dtor calls:
$ bin/clang++ -shared test3.cc -std=c++11 -O2 -fvisibility=hidden \
-fvisibility-inlines-hidden -o libtest3.dylib
$ bin/clang++ test2.cc -std=c++11 -O2 -fvisibility=hidden \
-fvisibility-inlines-hidden libtest3.dylib
Undefined symbols for architecture x86_64:
"B<int>::f()", referenced from:
vtable for B<int> in test2-af8f4f.o
ld: symbol(s) not found for architecture x86_64
What's happening here is that there's a copy of B's vtable hidden in
libtest3.dylib, because C's constructor caused an implicit instantiation of that
(and implicit constructors generate vtables).
test2.cc calls C's destructDr, which destroys the B<int> member,
which wants to overwrite the vtable back to B (think of B as the base of a class
hierarchy, and of hierarchical destruction -- maybe we shouldn't do the vtable
writing in destructors of final classes), but there's nothing in test2.cc that
marks B's vtable used. So codegen writes out the vtable, but since it wasn't
marked used, sema didn't mark all the virtual functions (in particular f())
as used.
Note that this change makes us reject programs we didn't reject before (see
the included Sema test case), but both gcc and cl also reject this code, and
clang used to reject it before r213109.
llvm-svn: 225761
|
| |
|
|
|
|
| |
Register are thread-local by default, so we have to consider them as threadprivate.
llvm-svn: 225759
|
| |
|
|
|
|
|
| |
Move the logic for checking self moves into SemaChecking and add that function
to Sema since it is now used in multiple places.
llvm-svn: 225756
|
| |
|
|
| |
llvm-svn: 225684
|
| |
|
|
| |
llvm-svn: 225624
|
| |
|
|
| |
llvm-svn: 225587
|
| |
|
|
|
|
|
|
| |
-Wself-move is similiar to -Wself-assign. This warning is triggered when
a value is attempted to be moved to itself. See r221008 for a bug that
would have been caught with this warning.
llvm-svn: 225581
|
| |
|
|
|
|
| |
cast notation T{...} when T is a reference type.
llvm-svn: 225571
|
| |
|
|
|
|
|
|
|
| |
We have a diagnostic describing that constexpr changed in C++14 when
compiling in C++11 mode. While doing this, it examines the previous
declaration and assumes that it is a function. However it is possible,
in the context of error recovery, for this to not be the case.
llvm-svn: 225518
|
| |
|
|
|
|
|
|
|
|
|
| |
Parser::ParseNamespace can get a little confused when it found itself
inside a compound statement inside of a non-static data member
initializer.
Try to determine that the statement expression's scope makes sense
before trying to parse it's contents.
llvm-svn: 225514
|
| |
|
|
| |
llvm-svn: 225513
|
| |
|
|
|
|
|
| |
RecordDecls should have things like CXXMethodDecls or FriendDecls as a
decl but not things like FunctionDecls.
llvm-svn: 225511
|
| |
|
|
|
|
|
|
| |
We assumed that class-scope specializations would result in a
CXXMethodDecl for that class. However, globally qualified functions
will result in normal FunctionDecls.
llvm-svn: 225508
|
| |
|
|
|
|
|
| |
The same code is already in Sema::ActOnFunctionDeclarator, the only
caller of CreateNewFunctionDecl.
llvm-svn: 225506
|
| |
|
|
|
|
|
|
|
|
| |
we're instantiating, if there's a ParmVarDecl within a FunctionDecl context
that is not a parameter of that function. Add some asserts to catch this kind
of issue more generally, and fix another bug exposed by those asserts where we
were missing a local instantiation scope around substitution of
explicitly-specified template arguments.
llvm-svn: 225490
|
| |
|
|
|
|
|
|
|
| |
better than the 'template-parameter-x-y' name that we'd get in AST printing,
and is worse in several ways (it's harder to distinguish it from a
user-supplied name, it's wrong after substituting some number of outer
levels, it wastes time and space constructing an IdentifierInfo, ...).
llvm-svn: 225489
|
| |
|
|
| |
llvm-svn: 225414
|
| |
|
|
|
|
|
|
|
|
|
|
| |
transform.
Also diagnose typos in the initializer of an invalid C++ declaration.
Both issues were hit using the same line of test code, depending on
whether the code was treated as C or C++.
Fixes PR22092.
llvm-svn: 225389
|
| |
|
|
| |
llvm-svn: 225324
|
| |
|
|
|
|
|
|
|
|
| |
Add additional constraint checking for target specific behaviour for inline
assembly constraints. We would previously silently let all arguments through
for these constraints. In cases where the constraints were violated, we could
end up failing to select instructions and triggering assertions or worse,
silently ignoring instructions.
llvm-svn: 225244
|
| |
|
|
| |
llvm-svn: 225128
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Also add a few asserts for this. The existing code assumes this in a bunch
of places already (see e.g. the assert at the top of ParseTypedefDecl(), and
there are many unchecked calls on the result of GetTypeForDeclarator()), and
from looking through the code this should always be true from what I can tell.
This allows removing ASTContext::getNullTypeSourceInfo() too as that's now
unused.
No behavior change intended.
llvm-svn: 225125
|
| |
|
|
|
|
|
|
|
|
| |
Many places in Sema cannot handle isNull() types. This is fine, because in
most places the type building code recovers by falling back to IntTy. In
GetFullTypeForDeclarator(), this is done at the end of the getNumTypeObjects()
loop body. This function calls BuildQualifiedType() before this fallback is
done though, so it explicitly needs to check for isNull() types.
llvm-svn: 225124
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instantiated. Do not crash in this case. Fixes PR22040!
The FIXME in the test is caused by TemplateDeclInstantiator::VisitCXXRecordDecl
returning a nullptr instead of creating an invalid decl. This is a common
pattern across all of TemplateDeclInstantiator, so I'm not comfortable changing
it. The reason it's not invalid in the class template is due to support for an
MSVC extension, see r137573.
llvm-svn: 225071
|
| |
|
|
| |
llvm-svn: 225004
|
| |
|
|
|
|
|
|
|
|
|
|
| |
clang tries to produce a helpful diagnostic for the traiilng '...', but the
code that r216778 added for this doesn't expect an invalid trailing return type.
Add code to explicitly handle this.
Having explicit code for this but not for other things looks a bit strange, but
trailing return types are special in that they have a separate existence bit in
addition to the type (see r158348).
llvm-svn: 224974
|
| |
|
|
|
|
|
|
| |
GCC permits array l-values in asm output operands even though they
aren't modifiable l-values. We used to permit it but this behavior
regressed in r224916.
llvm-svn: 224918
|
| |
|
|
|
|
|
|
|
|
| |
Functions are l-values in C++ but shouldn't be available as output
parameters in inline assembly. Neither should overloaded function
l-values.
This fixes PR21949.
llvm-svn: 224916
|
| |
|
|
|
|
|
|
| |
hasDeclaratorForAnonDecl, getDeclaratorForAnonDecl and
getTypedefNameForAnonDecl are expected to handle the case where
NamedDeclOrQualifier holds the wrong type or nothing at all.
llvm-svn: 224912
|
| |
|
|
|
|
| |
Verify that asm constraints have the same number of alternatives
llvm-svn: 224911
|
| |
|
|
|
|
|
| |
We correctly forbid variables but not variable templates. Diagnose this
case instead of crashing.
llvm-svn: 224905
|
| |
|
|
|
|
|
|
|
| |
We forgot a conversion step when initializing an atomic type with an
rvalue of the same type.
This fixes PR22043.
llvm-svn: 224902
|
| |
|
|
|
|
|
|
|
| |
We expected the type of a TagDecl to be a TagType, not an
InjectedClassNameType. Introduced a helper method, Type::getAsTagDecl,
to abstract away the difference; redefine Type::getAsCXXRecordDecl to be
in terms of it.
llvm-svn: 224898
|
| |
|
|
|
|
|
| |
Don't warn when a selector has an unavailable and an available variant,
and the first also has an implementation.
llvm-svn: 224881
|
| |
|
|
| |
llvm-svn: 224880
|
| |
|
|
|
|
|
|
|
|
|
| |
Remove ObjCMethodList::Count, instead store a "has more than one decl" bit in
the low bit of the ObjCMethodDecl pointer, using a PointerIntPair.
Most of this patch is replacing ".Method" with ".getMethod()".
No intended behavior change.
llvm-svn: 224876
|
| |
|
|
| |
llvm-svn: 224843
|
| |
|
|
|
|
|
|
|
|
| |
r224667 broke bootstrap on Fedora 20 X86_64 (at least).
See pr22006 for the details.
r224668 depends on r224667.
llvm-svn: 224770
|
| |
|
|
|
|
|
|
|
| |
When a non-type template argument expression needs a conversion to change it
into the argument type, preserve that information by remaking the
TemplateArgument with an expression that has those conversions. Also a small
fix to template type diffing to handle the extra conversions in some cases.
llvm-svn: 224667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider a template class with attributes on a method, and an explicit
specialization of that method:
template <int>
struct A {
void foo() final;
};
template <>
void A<0>::foo() {}
In this example, the attribute is `final`, but it might also be an
__attribute__((visibility("foo"))), noreturn, inline, etc. clang's current
behavior is to strip all attributes, which for some attributes is wrong
(the snippet above allows a subclass of A<0> to override the final method, for
example) and for others disagrees with gcc.
So stop dropping attributes. r95845 added this code without a test case, and
r176728 added the code for dropping attributes on parameters (with tests, but
they still pass).
As an additional wrinkle, do drop dllimport and dllexport, since that's how
these two attributes work. (This is covered by existing tests.)
Fixes PR21942.
The approach is by Richard Smith, initial analysis and typing was done by me.
With this, clang also matches GCC and EDG on all attributes Richard tested.
llvm-svn: 224651
|
| |
|
|
|
|
| |
lambda-expression in C++11, to match the C++14 rules.
llvm-svn: 224620
|
| |
|
|
|
|
|
|
| |
or an identifier. VariadicEnumArguments now behave consistently instead of only accepting a string literal.
This change affects the only attribute accepting a variadic enumeration: callable_when.
llvm-svn: 224582
|
| |
|
|
|
|
| |
declared return type (including a trailing-return-type in C++14).
llvm-svn: 224561
|
| |
|
|
|
|
|
|
| |
when source range is incorrect causing the warning to be
issued when it should not because expression is in a macro.
rdar://19256338
llvm-svn: 224549
|