declarations for implicit default constructors, copy constructors,
copy assignment operators, and destructors. On a "simple" translation
unit that includes a bunch of C++ standard library headers, we
generate relatively few of these implicit declarations now:
4/159 implicit default constructors created
18/236 implicit copy constructors created
70/241 implicit copy assignment operators created
0/173 implicit destructors created
And, on this translation unit, this optimization doesn't really
provide any benefit. I'll do some more performance measurements soon,
but this completes the implementation work for <rdar://problem/8151045>.
llvm-svn: 107551
As a bonus, fix the warning for || and && operators; it was emitted even if one of the operands had side effects, e.g:
x || test_logical_foo1();
emitted a bogus "expression result unused" for 'x'.
llvm-svn: 107274
This commit 'introduces' a slightly different way to restore the state of the AST object.
It makes PCHDeclReader/PCHDeclWriter friends and gives them access to the private members of the object.
The rationale is to avoid using/modifying the AST interfaces for PCH read/write so that to:
-Avoid complications with objects that have side-effects during creation or when using some setters.
-Not 'pollute' the AST interface with methods only used by the PCH reader/writer
-Allow AST objects to be read-only.
llvm-svn: 107219
there's an explicit guard on isPolymorphic, and virtual bases don't affect the
key function calculation. This allows people to call
ASTContext::getKeyFunction on arbitrary classes.
llvm-svn: 107143
__real myvec and __imag myvec, since they aren't all that useful (it's
just an identity function) but we might want to use them in more
restricted cases in the future (e.g., "__real mycomplexvec" could
extract the real parts of a vector of complex numbers).
llvm-svn: 106601
of the callers of isRealType() already assumed this, and one of them
(increment/decrement) mistakenly permitted increments of vector types
because of it.
llvm-svn: 106596
types, updating callers of both isFloatingType() and
isRealFloatingType() accordingly. Caught at least one issue where we
allowed one to declare a vector of vectors (!), along with cleaning up
the standard-conversion logic for C++.
llvm-svn: 106595
"floating type" in C, which does not include vector types. Introduce
Type::hasFloatingRepresentation() for the places where we want to know
whether the underlying representation is one or more floating-point
values. Remove some hacks we had where the former behavior of
Type::isFloatingType() was at odds with the language definition of the
term.
llvm-svn: 106584
Introduce:
-FunctionDecl::getTemplatedKind() which returns an enum signifying what kind of templated
FunctionDecl it is.
-An overload of FunctionDecl::setFunctionTemplateSpecialization() which accepts arrays of
TemplateArguments and TemplateArgumentLocs
-A constructor to TemplateArgumentList which accepts an array of TemplateArguments.
llvm-svn: 106532
if/while/switch/for statements to ensure that walking the children of
these statements actually works. Previously, we stored the condition
variable as a VarDecl. However, StmtIterator isn't able to walk from a
VarDecl to a set of statements, and would (in some circumstances) walk
beyond the end of the list of statements, cause Bad Behavior.
In this change, we've gone back to representing the condition
variables as DeclStmts. While not as memory-efficient as VarDecls, it
greatly simplifies iteration over the children.
Fixes the remainder of <rdar://problem/8104754>.
llvm-svn: 106504
attribute as part of the calculation. Sema::MarkDeclReferenced(), and
a few other places, want only to consider the "used" bit to determine,
e.g, whether to perform template instantiation. Fixes a linkage issue
with Boost.Serialization.
llvm-svn: 106252
Currently, there are two effective changes:
- Attr::Kind has been changed to attr::Kind, in a separate namespace
rather than the Attr class. This is because the enumerator needs to
be visible to parse.
- The class definitions for the C++0x attributes other than aligned are
generated by TableGen.
The specific classes generated by TableGen are controlled by an array in
TableGen (see the accompanying commit to the LLVM repository). I will be
expanding the amount of code generated as I develop the new attributes system
while initially keeping it confined to these attributes.
llvm-svn: 106172
provides C "integer type" semantics in C and C++ "integral type"
semantics in C++.
Note that I still need to update isIntegerType (and possibly other
predicates) using the same approach I've taken for
isIntegralType(). The two should have the same meaning, but currently
don't (!).
llvm-svn: 106074
in C++ that involve both integral and enumeration types. Convert all
of the callers to Type::isIntegralType() that are meant to work with
both integral and enumeration types over to
Type::isIntegralOrEnumerationType(), to prepare to eliminate
enumeration types as integral types.
llvm-svn: 106071
Decl.cpp:716:28: warning: initialization of pointer of type 'clang::VarDecl *' from literal 'false' [-Wbool-conversions]
VarDecl *LastTentative = false;
^
RewriteRope.cpp:535:12: warning: initialization of pointer of type '<anonymous>::RopePieceBTreeNode *' from literal 'false'
[-Wbool-conversions]
return false;
^
llvm-svn: 105946
case of an elaborated-type-specifier like 'typename A<T>::foo', and
DependentTemplateSpecializationType represents the case of an
elaborated-type-specifier like 'typename A<T>::template B<T>'. The TypeLoc
representation of a DependentTST conveniently exactly matches that of an
ElaboratedType wrapping a TST.
Kill off the explicit rebuild methods for RebuildInCurrentInstantiation;
the standard implementations work fine because the nested name specifier
is computable in the newly-entered context.
llvm-svn: 105801
being a subsequence of another standard conversion sequence. Instead
of requiring exact type equality for the second conversion step,
require type *similarity*, which is type equality with cv-qualifiers
removed at all levels. This appears to match the behavior of EDG and
VC++ (albeit not GCC), and feels more intuitive. Big thanks to John
for the line of reasoning that supports this change: since
cv-qualifiers are orthogonal to the second conversion step, we should
ignore them in the type comparison.
llvm-svn: 105678
bring in the entire lookup table at once.
Also, give ExternalSemaSource's vtable a home. This is important because otherwise
any reference to it will cause RTTI to be emitted, and since clang is compiled
with -fno-rtti, that RTTI will contain unresolved references (to ExternalASTSource's
RTTI). So this change makes it possible to subclass ExternalSemaSource from projects
compiled with RTTI, as long as the subclass's home is compiled with -fno-rtti.
llvm-svn: 105268
The macros required for DeclNodes use have changed to match the use of
StmtNodes. The FooFirst enumerator constants have been named firstFoo
to match usage elsewhere.
llvm-svn: 105165
the x86-64 __va_list_tag with this attribute. The attribute causes the
affected type to behave like a fundamental type when considered by ADL.
(x86-64 is the only target we currently provide with a struct-based
__builtin_va_list)
Fixes PR6762.
llvm-svn: 104941
Flag synthesized struct decl. as non-empty so
CXX side of ir gen does not skip its Null initialization.
Fixes radar 8027844 for objc++'s collection statement.
llvm-svn: 104837
a massive memory leak when using a BumpPtrAllocator in ASTContext.
Added a FIXME, as the Destroy method for TemplateArgumentList isn't getting called.
This means we will instead leak when using the MallocAllocator.
llvm-svn: 104633
VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (which
would be very bad).
llvm-svn: 104471
pointers in the ASTContext, so that the folding sets stored inside
them will be deallocated when the ASTContext is destroyed (under
-disable-free). <rdar://problem/7998824>.
llvm-svn: 104465
instead of new[]'d. This greatly reduces the number of new[]'s, and guess what,
they were all leaked.
This adds a fixme in this hunk:
unsigned NumPackArgs = NumFlatArgs - PackBeginIndex;
+ // FIXME: NumPackArgs shouldn't be negative here???
if (NumPackArgs)
- PackArgs = &FlatArgs[PackBeginIndex];
+ PackArgs = FlatArgs.data()+PackBeginIndex;
where test/SemaTemplate/variadic-class-template-2.cpp is accessing the vector
out of range and NumPackArgs is negative. I assume variadic template args are
completely hosed.
llvm-svn: 104194
initializer, don't fold paramters. Their initializers are just default
arguments which can be overridden. This fixes some spectacular regressions due
to more things making it into the constant folding.
llvm-svn: 103904
ObjCObjectType, which is basically just a pair of
one of {primitive-id, primitive-Class, user-defined @class}
with
a list of protocols.
An ObjCObjectPointerType is therefore just a pointer which always points to
one of these types (possibly sugared). ObjCInterfaceType is now just a kind
of ObjCObjectType which happens to not carry any protocols.
Alter a rather large number of use sites to use ObjCObjectType instead of
ObjCInterfaceType. Store an ObjCInterfaceType as a pointer on the decl rather
than hashing them in a FoldingSet. Remove some number of methods that are no
longer used, at least after this patch.
By simplifying ObjCObjectPointerType, we are now able to easily remove and apply
pointers to Objective-C types, which is crucial for a certain kind of ObjC++
metaprogramming common in WebKit.
llvm-svn: 103870
references. This is a WIP as we should handle function pointers, etc. Reshuffle
the code to do this to facilitate recursing in this manner, and to check for
the type already being printed first rather than last.
llvm-svn: 103712
value-dependent if their initializers are value-dependent; my recent
tweak to these dependent rules overstepped by taking away this
value-dependents. Fixes a Boost.GIL regression.
llvm-svn: 103476
of the current instantiation is value-dependent. The C++ standard
fails to enumerate this case and, therefore, we missed it. Chandler
did all of the hard work of reducing the last remaining
Boost.PtrContainer failure (which had to do with static initialization
in the Serialization library) down to this simple little test.
While I'm at it, clean up the dependence rules for template arguments
that are declarations, and implement the dependence rules for template
argument packs.
llvm-svn: 103464
of constant-evaluation. Formerly you could control whether it accepted
local l-values or not; now it always evaluates local l-values in the core
routines, but filters them out where consumed by the top-level routines.
This will make it much easier to cache evaluability.
llvm-svn: 103444
While DeclarationNameTable doesn't leak, it uses 'malloc' too often. Start with having
'CXXLiteralOperatorNames' allocated using ASTContext's allocator and add a 'DoDestroy()' method
to DeclarationNameTable that is called by ~ASTContext.
llvm-svn: 103426
conflicting deduced template argument values, give a more specific
reason along with those values, e.g.,
test/SemaTemplate/overload-candidates.cpp:4:10: note: candidate template
ignored: deduced conflicting types for parameter 'T' ('int' vs. 'long')
const T& min(const T&, const T&);
^
llvm-svn: 103339
but whose operand isn't a float: specifically, __real__ and __imag__. Instead
of filtering these out, just implement them.
Fixes <rdar://problem/7958272>.
llvm-svn: 103307
inlineable. That header file has to be TypeLoc.h, which means that
TypeLoc.h needs to depend on Decl.h because TypeSourceInfo doesn't
have its own header. That could be remedied, though.
llvm-svn: 103176
different tag kind ("struct" vs. "class") than the primary template,
which has an affect on access control.
Should fix the last remaining Boost.Accumulors failure.
llvm-svn: 103144
except it only skips implicit casts.
Also fix ObjCImplicitGetterSetterRefExpr's child_begin to skip the base expression
if it's actually a type reference (which you get with static property references).
llvm-svn: 103132
implicitly-generated copy constructor. Previously, Sema would perform
some checking and instantiation to determine which copy constructors,
etc., would be called, then CodeGen would attempt to figure out which
copy constructor to call... but would get it wrong, or poke at an
uninstantiated default argument, or fail in other ways.
The new scheme is similar to what we now do for the implicit
copy-assignment operator, where Sema performs all of the semantic
analysis and builds specific ASTs that look similar to the ASTs we'd
get from explicitly writing the copy constructor, so that CodeGen need
only do a direct translation.
However, it's not quite that simple because one cannot explicit write
elementwise copy-construction of an array. So, I've extended
CXXBaseOrMemberInitializer to contain a list of indexing variables
used to copy-construct the elements. For example, if we have:
struct A { A(const A&); };
struct B {
A array[2][3];
};
then we generate an implicit copy assignment operator for B that looks
something like this:
B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { }
CodeGen will loop over the invented variables i0 and i1 to visit all
elements in the array, so that each element in the destination array
will be copy-constructed from the corresponding element in the source
array. Of course, if we're dealing with arrays of scalars or class
types with trivial copy-assignment operators, we just generate a
memcpy rather than a loop.
Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes
all of its regression tests.
Conspicuously missing from this patch is handling for the exceptional
case, where we need to destruct those objects that we have
constructed. I'll address that case separately.
llvm-svn: 103079
assignment operators.
Previously, Sema provided type-checking and template instantiation for
copy assignment operators, then CodeGen would synthesize the actual
body of the copy constructor. Unfortunately, the two were not in sync,
and CodeGen might pick a copy-assignment operator that is different
from what Sema chose, leading to strange failures, e.g., link-time
failures when CodeGen called a copy-assignment operator that was not
instantiation, run-time failures when copy-assignment operators were
overloaded for const/non-const references and the wrong one was
picked, and run-time failures when by-value copy-assignment operators
did not have their arguments properly copy-initialized.
This implementation synthesizes the implicitly-defined copy assignment
operator bodies in Sema, so that the resulting ASTs encode exactly
what CodeGen needs to do; there is no longer any special code in
CodeGen to synthesize copy-assignment operators. The synthesis of the
body is relatively simple, and we generate one of three different
kinds of copy statements for each base or member:
- For a class subobject, call the appropriate copy-assignment
operator, after overload resolution has determined what that is.
- For an array of scalar types or an array of class types that have
trivial copy assignment operators, construct a call to
__builtin_memcpy.
- For an array of class types with non-trivial copy assignment
operators, synthesize a (possibly nested!) for loop whose inner
statement calls the copy constructor.
- For a scalar type, use built-in assignment.
This patch fixes at least a few tests cases in Boost.Spirit that were
failing because CodeGen picked the wrong copy-assignment operator
(leading to link-time failures), and I suspect a number of undiagnosed
problems will also go away with this change.
Some of the diagnostics we had previously have gotten worse with this
change, since we're going through generic code for our
type-checking. I will improve this in a subsequent patch.
llvm-svn: 102853
specializations, which keeps track of the order in which they were
originally declared. We use this number so that we can always walk the
list of partial specializations in a predictable order during matching
or template instantiation. This also fixes a failure in Boost.Proto,
where SourceManager::isBeforeInTranslationUnit was behaving
poorly in inconsistent ways.
llvm-svn: 102693
InjectedClassNameType's Decl to point at the definition. It's a little
messy, but we do the same thing with classes and their record types,
since much of Clang expects that the TagDecl* one gets out of a type
is the definition. Fixes several Boost.Proto failures.
llvm-svn: 102691
address of an overloaded function (or function template), perform that
resolution prior to determining the implicit conversion
sequence. This resolution is not part of the implicit conversion
sequence itself.
Previously, we would always consider this resolution to be a
function pointer decay, which was a lie: there might be an explicit &
in the expression, in which case decay should not occur. This caused
the CodeGen assertion in PR6973 (where we created a
pointer to a pointer to a function when we should have had a pointer
to a function), but it's likely that there are corner cases of
overload resolution where this would have failed.
Cleaned up the code involved in determining the type that will
produced afer resolving the overloaded function reference, and added
an assertion to make sure the result is correct. Fixes PR6973.
llvm-svn: 102650
classes, since we only warn (not error) on offsetof() for non-POD
types. We store the base path within the OffsetOfExpr itself, then
evaluate the offsets within the constant evaluator.
llvm-svn: 102571
Amadini.
This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.
OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.
There are two major caveats to this patch:
1) CodeGen cannot handle the case where __builtin_offsetof is not a
constant expression, so it produces an error. So, to avoid
regressing in C, we retain the old UnaryOperator-based
__builtin_offsetof implementation in C while using the shiny new
OffsetOfExpr implementation in C++. The old implementation can go
away once we have proper CodeGen support for this case, which we
expect won't cause much trouble in C++.
2) __builtin_offsetof doesn't work well with non-POD class types,
particularly when the designated field is found within a base
class. I will address this in a subsequent patch.
Fixes PR5880 and a bunch of assertions when building Boost.Python
tests.
llvm-svn: 102542
keep track of whether we need to zero-initialize storage prior to
calling its constructor. Previously, we were only tracking this when
implicitly constructing the object (a CXXConstructExpr).
Fixes Boost's value-initialization tests, which means that the
Boost.Config library now passes all of its tests.
llvm-svn: 102461
UnresolvedLookupExpr and UnresolvedMemberExpr by substituting the
naming class we computed when building the expression in the
template...
... which we didn't always do correctly. Teach
UnresolvedMemberExpr::getNamingClass() all about the new
representation of injected-class-names in templates, so that it can
return a naming class that is the current instantiation.
Also, when decomposing a template-id into its template name and its
arguments, be sure to set the naming class on the LookupResult
structure.
Fixes PR6947 the right way.
llvm-svn: 102448
of a class template or class template partial specialization. That is to
say, in
template <class T> class A { ... };
or
template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context. This allows us to track the
current instantiation appropriately even inside AST routines. It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).
llvm-svn: 102407
by using TypeSourceInfo, cleaning up the representation
somewhat. Teach getTypeOperand() to strip references and
cv-qualifiers, providing the semantic view of the type without
requiring any extra storage (the unmodified type remains within the
TypeSourceInfo). This fixes a bug found by Boost's call_traits test.
Finally, clean up semantic analysis, by splitting the ActOnCXXTypeid
routine into ActOnCXXTypeId (the parser action) and two BuildCXXTypeId
functions, which perform the semantic analysis for typeid(type) and
typeid(expression), respectively. We now perform less work at template
instantiation time (we don't look for std::type_info again) and can
give better diagnostics.
llvm-svn: 102393
thing. Audit all uses of Type::isStructure(), changing those calls to
isStructureOrClassType() as needed (which is alsmost
everywhere). Fixes the remaining failure in Boost.Utility/Swap.
llvm-svn: 102386
statements. Instead of the @try having a single @catch, where all of
the @catch's were chained (using an O(n^2) algorithm nonetheless),
@try just holds an array of its @catch blocks. The resulting AST is
slightly more compact (not important) and better represents the actual
language semantics (good).
llvm-svn: 102221
way that C does. Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might imagine, does not
include typedefs. Rework our use of IDNS masks to capture the semantics
of different kinds of declarations better, and remove most current lookup
filters. Removing the last remaining filter is more complicated and will
happen in a separate patch.
Fixes PR 6885 as well some spectrum of unfiled bugs.
llvm-svn: 102164
address of overloaded function, instead of assuming that a nested name
specifier was used. A nested name specifier is not required for static
functions.
Fixes PR6886.
llvm-svn: 102107
support dependent receivers for class and instance messages, along
with dependent message arguments (of course), and check as much as we
can at template definition time.
This commit also deals with a subtle aspect of template instantiation
in Objective-C++, where the type 'T *' can morph from a dependent
PointerType into a non-dependent ObjCObjectPointer type.
llvm-svn: 102071
expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. The ObjCMessageExpr node represents four different kinds of
message sends in a single AST node:
1) Send to a object instance described by an expression (e.g., [x method:5])
2) Send to a class described by the class name (e.g., [NSString method:5])
3) Send to a superclass class (e.g, [super method:5] in class method)
4) Send to a superclass instance (e.g., [super method:5] in instance method)
Previously these four cases where tangled together. Now, they have
more distinct representations. Specific changes:
1) Unchanged; the object instance is represented by an Expr*.
2) Previously stored the ObjCInterfaceDecl* referring to the class
receiving the message. Now stores a TypeSourceInfo* so that we know
how the class was spelled. This both maintains typedef information
and opens the door for more complicated C++ types (e.g., dependent
types). There was an alternative, unused representation of these
sends by naming the class via an IdentifierInfo *. In practice, we
either had an ObjCInterfaceDecl *, from which we would get the
IdentifierInfo *, or we fell into the case below...
3) Previously represented by a class message whose IdentifierInfo *
referred to "super". Sema and CodeGen would use isStr("super") to
determine if they had a send to super. Now represented as a
"class super" send, where we have both the location of the "super"
keyword and the ObjCInterfaceDecl* of the superclass we're
targetting (statically).
4) Previously represented by an instance message whose receiver is a
an ObjCSuperExpr, which Sema and CodeGen would check for via
isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
where we have both the location of the "super" keyword and the
ObjCInterfaceDecl* of the superclass we're targetting
(statically). Note that ObjCSuperExpr only has one remaining use in
the AST, which is for "super.prop" references.
The new representation of ObjCMessageExpr is 2 pointers smaller than
the old one, since it combines more storage. It also eliminates a leak
when we loaded message-send expressions from a precompiled header. The
representation also feels much cleaner to me; comments welcome!
This patch attempts to maintain the same semantics we previously had
with Objective-C message sends. In several places, there are massive
changes that boil down to simply replacing a nested-if structure such
as:
if (message has a receiver expression) {
// instance message
if (isa<ObjCSuperExpr>(...)) {
// send to super
} else {
// send to an object
}
} else {
// class message
if (name->isStr("super")) {
// class send to super
} else {
// send to class
}
}
with a switch
switch (E->getReceiverKind()) {
case ObjCMessageExpr::SuperInstance: ...
case ObjCMessageExpr::Instance: ...
case ObjCMessageExpr::SuperClass: ...
case ObjCMessageExpr::Class:...
}
There are quite a few places (particularly in the checkers) where
send-to-super is effectively ignored. I've placed FIXMEs in most of
them, and attempted to address send-to-super in a reasonable way. This
could use some review.
llvm-svn: 101972
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
llvm-svn: 101826
- Used to determine whether the alignment of the type in a bit-field is
respected when laying out structures. The default is true, targets can
override this as needed.
- This is designed to correspond to the PCC_BITFIELD_TYPE_MATTERS macro in
gcc. The AST/Sema implementation only affects one line, unless I have
forgotten something. I'd appreciate further review.
- IRgen still needs to be updated to fully support this (which is effectively
PR5591).
llvm-svn: 101356
parameter, explicitly ask the user to give it arguments. We used to
complain that it wasn't a type and expect the user to figure it out.
llvm-svn: 100729
that protected members be used on objects of types which derive from the
naming class of the lookup. My first N attempts at this were poorly-founded,
largely because the standard is very badly worded here.
llvm-svn: 100562
poor (and wrong) approximation of the actual rules governing when to
build a copy and when it can be elided.
The correct implementation is actually simpler than the
approximation. When we only enumerate constructors as part of
initialization (e.g., for direct initialization or when we're copying
from a class type or one of its derived classes), we don't create a
copy. When we enumerate all conversion functions, we do create a
copy. Before, we created some extra copies and missed some
others. The new test copy-initialization.cpp shows a case where we
missed creating a (required, non-elidable) copy as part of a
user-defined conversion, which resulted in a miscompile. This commit
also fixes PR6757, where the missing copy made us reject well-formed
code in the ternary operator.
This commit also cleans up our handling of copy elision in the case
where we create an extra copy of a temporary object, which became
necessary now that we produce the right copies. The code that seeks to
find the temporary object being copied has moved into
Expr::getTemporaryObject(); it used to have two different
not-quite-the-same implementations, one in Sema and one in CodeGen.
Note that we still do not attempt to perform the named return value
optimization, so we miss copy elisions for return values and throw
expressions.
llvm-svn: 100196
(such as "class T::foo") from an ElaboratedType of a TypenameType to a
DependentNameType, which more accurately models the underlying
concept.
Improve template instantiation for DependentNameType nodes that
represent nested-name-specifiers, by performing tag name lookup and
checking the resulting tag appropriately. Fixes PR5681.
There is still much testing and cleanup to do in this area.
llvm-svn: 100054
the underlying/instantiated decl) through a lot of API, including "intermediate"
MemberExprs required for (e.g.) template instantiation. This is necessary
because of the access semantics of member accesses to using declarations:
only the base class *containing the using decl* need be accessible from the
naming class.
This allows us to complete an access-controlled selfhost, if there are no
recent regressions.
llvm-svn: 99936
This introduces FunctionType::ExtInfo to hold the calling convention and the
noreturn attribute. The next patch will extend it to include the regparm
attribute and fix the bug.
llvm-svn: 99920
dyn_cast) invocations for C++ and Objective-C types, declarations,
expressions, and statements. The statistics will be printed when
-print-stats is provided to Clang -cc1, with results such as:
277073 clang - Number of checks for C++ declaration nodes
13311 clang - Number of checks for C++ expression nodes
18 clang - Number of checks for C++ statement nodes
174182 clang - Number of checks for C++ type nodes
92300 clang - Number of checks for Objective-C declaration nodes
9800 clang - Number of checks for Objective-C expression nodes
7 clang - Number of checks for Objective-C statement nodes
65733 clang - Number of checks for Objective-C type nodes
The statistics are only gathered when NDEBUG is not defined, since
they introduce potentially-expensive operations into very low-level
routines (isa).
llvm-svn: 99912
storage for that partial diagnostic via the ASTContext's
BumpPtrAllocator rather than using up slots in the ASTContext's
cache. Now that we do this, we don't have to worry about destroying
dependent diagnostics when destroying a DependentStoredDeclsMap.
llvm-svn: 99854
cache of PartialDiagnostic::Storage objects into an allocator within
the ASTContext. This eliminates a significant amount of malloc
traffic, for a 10% performance improvement in -fsyntax-only wall-clock
time with 403.gcc's combine.c.
Also, eliminate the RequireNonAbstractType hack I put in earlier,
which was but a symptom of this larger problem.
Fixes <rdar://problem/7806091>.
llvm-svn: 99849
What happens here is that we actually turn the first declaration into a
definition, regardless of whether it was actually originally a definition,
and furthermore we do this all after we've instantiated all the declarations.
This exposes a bug in my DefinitionData patch where it was only setting the
DefinitionData for previous declarations, not future declarations.
Fortunately, there's an iterator for that.
llvm-svn: 99657
templates. So delay access-control diagnostics when (for example) the target
of a friend declaration is a specific specialization of a template.
I was surprised to find that this was required for an access-controlled selfhost.
llvm-svn: 99383
function within a class hierarchy (C++ [class.virtual]p2).
We use the final-overrider computation to determine when a particular
class is ill-formed because it has multiple final overriders for a
given virtual function (e.g., because two virtual functions override
the same virtual function in the same virtual base class). Fixes
PR5973.
We also use the final-overrider computation to determine which virtual
member functions are pure when determining whether a class is
abstract or diagnosing the improper use of an abstract class. The
prior approach to determining whether there were any pure virtual
functions in a class didn't cope with virtual base class subobjects
properly, and could not easily be fixed to deal with the oddities of
subobject hiding. Fixes PR6631.
llvm-svn: 99351
implementation or synthesized into an implementation. Also,
fixes a code gen. bug when ivars are itroduced in interleaved
implementations. (related to radar 7547942).
llvm-svn: 99193
expression computation in the wrong bit-width, and end up generating a totally
bogus array reference (_g0+8589934546).
- This showed up on Prolangs/cdecl.
llvm-svn: 99042
ranges as part of the ASTContext. This code is not and was never used,
but contributes ~250k to the size of the Cocoa.h precompiled
header.
llvm-svn: 99007
SourceManager's getBuffer() (and similar) operations. This abstract
can be used to force callers to cope with errors in getBuffer(), such
as missing files and changed files. Fix a bunch of callers to use the
new interface.
Add some very basic checks for file consistency (file size,
modification time) into ContentCache::getBuffer(), although these
checks don't help much until we've updated the main callers (e.g.,
SourceManager::getSpelling()).
llvm-svn: 98585
on unqualified declarations.
Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes
with the ASTContext and delete them during Destroy(). I audited a bunch of
Destroy methods at the same time, to ensure that the correct teardown was
being done.
llvm-svn: 98540
Fixes an assertion arising C overload analysis, but really I can't imagine
that this wouldn't cause a thousand other uncaught failures.
Fixes PR6600.
llvm-svn: 98400
the @implementation (instead of the @interface) and actually add
the ivar to the DeclContext (which we weren't doing before).
This allows us to simplify ASTContext::CollectNonClassIvars() by
removing ASTContext::CollectProtocolSynthesizedIvars(). Now all
ivars can be found by either inspecting the ObjCInterfaceDecl and
its companion ObjCImplementationDecl.
llvm-svn: 98280
I'm expecting this portion of the AST to grow and change, and I'd like to
be able to do that with minimal recompilation. If this proves unnecessary
when access control is fully-implemented, I'll fold the classes back into
DeclCXX.h.
llvm-svn: 98249
claim this is C. We don't make ElaboratedTypes in C, but sometimes
the language options during pretty-print lie to us.
The rewriter should really be fixed to not rely on how types are pretty-printed,
though.
llvm-svn: 98189
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
llvm-svn: 98149
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
llvm-svn: 98134
that are hidden by other derived base subobjects reached along a
lookup path that does *not* pass through the hiding subobject (C++
[class.member.lookup]p6). Fixes PR6462.
llvm-svn: 97640
category. Use this in a few places to eliminate unnecessary TST cases and
do some future-proofing. Provide terrible manglings for typeof. Mangle
decltype with some hope of accuracy.
Our manglings for some of the cases covered in the testcase are different
from gcc's, which I've raised as an issue with the ABI list.
llvm-svn: 97523
how we find the operator delete that matches withe operator new we
found in a C++ new-expression.
This will also need CodeGen support. On a happy note, we're now a
"nans" away from building tramp3d-v4.
llvm-svn: 97209
expressions that look like pseudo-destructors, e.g.,
p->T::~T()
where p has dependent type.
At template instantiate time, we determine whether we actually have a
pseudo-destructor or a member access, and funnel down to the
appropriate routine in Sema.
Fixes PR6380.
llvm-svn: 97092
CXXPseudoDestructorExpr.
Update template instantiation for pseudo-destructor expressions to use
this source information and to make use of
Sema::BuildPseudoDestructorExpr when the base expression is dependent
or refers to a scalar type.
llvm-svn: 97079
__alignof__ operator, make sure to take into account the packed alignment
of the struct/union/class itself. Matches GCC's behavior and fixes PR6362.
llvm-svn: 96884
1) emit base destructors as aliases to their unique base class destructors
under some careful conditions. This is enabled for the same targets that can
support complete-to-base aliases, i.e. not darwin.
2) Emit non-variadic complete constructors for classes with no virtual bases
as calls to the base constructor. This is enabled on all targets and in
theory can trigger in situations that the alias optimization can't (mostly
involving virtual bases, mostly not yet supported).
These are bundled together because I didn't think it worthwhile to split them,
not because they really need to be.
llvm-svn: 96842
fixing up a few callers that thought they were propagating NoReturn
information but were in fact saying something about exception
specifications.
llvm-svn: 96766
are for out of line declarations more easily. This simplifies the logic and
handles the case of out-of-line class definitions correctly. Fixes PR6107.
llvm-svn: 96729
to initializer expressions in an array allocated using ASTContext.
This plugs a memory leak when ASTContext uses a BumpPtrAllocator to
allocate memory for AST nodes.
In my mind this isn't an ideal solution; it would be nice to have
a general "vector"-like class that allocates memory using ASTContext,
but whose guts could be separated from the methods of InitListExpr
itself. I haven't gone and taken this approach yet because it isn't
clear yet if we'll eventually want an alternate solution for recylcing
memory using by InitListExprs as we are constructing the ASTs.
llvm-svn: 96642
which describes temporary objects of class type in C++. Use this to
provide a more-specific, remappable diagnostic when takin the address
of such a temporary.
llvm-svn: 96396
comparing their types under the assumption that they are equivalent,
rather than importing the types and then checking for compatibility. A
few minor tweaks here:
- Teach structural matching to handle compatibility between
function types with prototypes and those without prototypes.
- Teach structural matching that an incomplete record decl is the
same as any other record decl with the same name.
- Keep track of pairs of declarations that we have already checked
(but failed to find as structurally matching), so we don't emit
diagnostics repeatedly.
- When importing a typedef of an anonymous tag, be sure to link the
imported tag type to its typedef.
With these changes, we survive a repeated import of <stdlib.h> and
<stdio.h>. Alas, the ASTNodeImporter is getting a little grotty.
llvm-svn: 96298
two types in different AST contexts are equivalent. Rather than
transforming the type from one context into the other context, we
perform a deep structural comparison of the types. This change
addresses a serious problem with recursive data types like
struct ListNode {
int value;
struct ListNode *Next;
} xList;
llvm-svn: 96278
those declared in it. This is to allow duplicate
property diagnostics for properties declared in class extensions
multiple times (radar 7629420) and for future use.
llvm-svn: 96276
incompatibility and show where the structural differences are. For
example:
struct1.c:36:8: warning: type 'struct S7' has incompatible definitions
in different translation units
struct S7 { int i : 8; unsigned j : 8; } x7;
^
struct1.c:36:33: note: bit-field 'j' with type 'unsigned int' and length 8 here
struct S7 { int i : 8; unsigned j : 8; } x7;
^
struct2.c:33:33: note: bit-field 'j' with type 'unsigned int' and length 16 here
struct S7 { int i : 8; unsigned j : 16; } x7;
^
There are a few changes to make this work:
- ASTImporter now has only a single Diagnostic object, not multiple
diagnostic objects. Otherwise, having a warning/error printed via
one Diagnostic and its note printed on the other Diagnostic could
cause the note to be suppressed.
- Implemented import functionality for IntegerLiteral (along with
general support for statements and expressions)
llvm-svn: 95900
array associated with NonNullAttr. This fixes yet another leak when
ASTContext uses a BumpPtrAllocator.
Fixes: <rdar://problem/7637150>
llvm-svn: 95863
storing the set of StoredDeclsMaps in an internal vector of void*.
This isn't an ideal solution, but for the time being this fixes a
major memory leak with these DenseMaps not being freed.
Fixes: <rdar://problem/7634755>
llvm-svn: 95861
array allocated using the allocator in ASTContext. This addresses
these strings getting leaked when using a BumpPtrAllocator (in
ASTContext).
Fixes: <rdar://problem/7636765>
llvm-svn: 95853
attribute, so it uses Anton's new target-specific attribute support. It's
supposed to ensure that the stack is 16-byte aligned, but since necessary
support is lacking from LLVM, this is a no-op for now.
llvm-svn: 95820
merged with variables of constant array types. Also, make sure that we
call DiagnosticClient's BeginSourceFile/EndSourceFile, so that it has
a LangOptions to work with.
llvm-svn: 95782
into another AST, including their include history. Here's an example
error that involves a conflict merging a variable with different types
in two translation units (diagnosed in the third AST context into
which everything is merged).
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var2.c:3:5:
error: external variable 'x2' declared with incompatible types in
different translation units ('int' vs. 'double')
int x2;
^
In file included from
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.c:3:
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.h:1:8:
note: declared here with type 'double'
double x2;
^
Although we maintain include history, we do not maintain macro
instantiation history across a merge. Instead, we map down to the
spelling location (for now!).
llvm-svn: 95732
attribute properly and avoid bogus warning. This is
an objective-c fix only. objective-c++ follows different code
pass and requires separate fix (which will come at a later time).
Fixes radar 7214820.
llvm-svn: 95571
follows (as conservatively as possible) gcc's current behavior: attributes
written on return types that don't apply there are applied to the function
instead, etc. Only parse CC attributes as type attributes, not as decl attributes;
don't accepet noreturn as a decl attribute on ValueDecls, either (it still
needs to apply to other decls, like blocks). Consistently consume CC/noreturn
information throughout codegen; enforce this by removing their default values
in CodeGenTypes::getFunctionInfo().
llvm-svn: 95436
one context and import them into another context, merging them
according to language-specific rules. This is a skeleton. It doesn't
work, it isn't testable, but I want it in version control.
llvm-svn: 95395
of a C++ record. Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition. Also cuts down on memory usage.
llvm-svn: 95330
ton of potential crashes of the same kind. The fundamental problem is
that type creation was following a dangerous pattern when using its
FoldingSets:
1) Use FindNodeOrInsertPos to see if the type is available
2) If not, and we aren't looking at a canonical type, build the
canonical type
3) Build and insert the new node into the FoldingSet
The problem here is that building the canonical type can, in very rare
circumstances, force the hash table inside the FoldingSet to
reallocate. That invalidates the insertion position we computed in
step 1, and in step 3 we end up inserting the new node into the wrong
place. BOOM!
I've audited all of ASTContext, fixing this problem everywhere I found
it. The vast majority of wrong code was C++-specific (and *ahem*
written by me), so I also audited other major folding sets in the C++
code (e.g., template specializations), but found no other instances of
this problem.
llvm-svn: 95315
void f(int a = 10) {
return a;
}
would always return 10, regardless of the passed in argument.
This fixes another 600 test failures. We're now down to only 137 failures!
llvm-svn: 95262
that is in an anonymous namespace, give that function or variable
internal linkage.
This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:
- Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
when the declaration is in an anonymous namespace.
- Added Type::getLinkage() to determine the linkage of a type, which
is defined as the minimum linkage of the types (when we're dealing
with a compound type that is not a struct/class/union).
- Extended NamedDecl::getLinkage() to consider the linkage of the
template arguments and template parameters of function template
specializations and class template specializations.
- Taught code generation to rely on NamedDecl::getLinkage() when
determining the linkage of variables and functions, also
considering the linkage of the types of those variables and
functions (C++ only). Map UniqueExternalLinkage to internal
linkage, taking out the explicit checks for
isInAnonymousNamespace().
This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:
LLVM:
Expected Passes : 4006
Expected Failures : 32
Unsupported Tests : 40
Unexpected Failures: 736
Clang:
Expected Passes : 1903
Expected Failures : 14
Unexpected Failures: 75
Overall:
Expected Passes : 5909
Expected Failures : 46
Unsupported Tests : 40
Unexpected Failures: 811
Still to do:
- Improve testing
- Check whether we should allow the presence of types with
InternalLinkage (in addition to UniqueExternalLinkage) given
variables/functions internal linkage in C++, as mentioned in
PR5792.
- Determine how expensive the getLinkage() calls are in practice;
consider caching the result in NamedDecl.
- Assess the feasibility of Chris's idea in comment #1 of PR5792.
llvm-svn: 95216
- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon. This also simplifies the code generated by the GNU runtime a bit.
- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.
- Recognise @selector() expressions as valid static initialisers (as GCC does).
- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants. These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.
- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector. This is needed for generating typed selectors from @selector() expressions (as GCC does). Ideally, this information should be stored in the Selector, but that would be an invasive change. We should eventually add checks for common uses of @selector() expressions. Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:
- (id)performSelector: __attribute__((selector_types(id, SEL, id)))(SEL)
withObject: (id)object;
Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature. We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.
- Made @selector() expressions emit type info if available and the runtime supports it.
Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac. This currently just assert()s.
llvm-svn: 95189
WHAT!?!
It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.
In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types
llvm-svn: 95117
(necessarily simultaneous) changes:
- CXXBaseOrMemberInitializer now contains only a single initializer
rather than a set of initialiation arguments + a constructor. The
single initializer covers all aspects of initialization, including
constructor calls as necessary but also cleanup of temporaries
created by the initializer (which we never handled
before!).
- Rework + simplify code generation for CXXBaseOrMemberInitializers,
since we can now just emit the initializer as an initializer.
- Switched base and member initialization over to the new
initialization code (InitializationSequence), so that it
- Improved diagnostics for the new initialization code when
initializing bases and members, to match the diagnostics produced
by the previous (special-purpose) code.
- Simplify the representation of type-checked constructor initializers in
templates; instead of keeping the fully-type-checked AST, which is
rather hard to undo at template instantiation time, throw away the
type-checked AST and store the raw expressions in the AST. This
simplifies instantiation, but loses a little but of information in
the AST.
- When type-checking implicit base or member initializers within a
dependent context, don't add the generated initializers into the
AST, because they'll look like they were explicit.
- Record in CXXConstructExpr when the constructor call is to
initialize a base class, so that CodeGen does not have to infer it
from context. This ensures that we call the right kind of
constructor.
There are also a few "opportunity" fixes here that were needed to not
regress, for example:
- Diagnose default-initialization of a const-qualified class that
does not have a user-declared default constructor. We had this
diagnostic specifically for bases and members, but missed it for
variables. That's fixed now.
- When defining the implicit constructors, destructor, and
copy-assignment operator, set the CurContext to that constructor
when we're defining the body.
llvm-svn: 94952
requires a temporary. Previously, we were building an initialization
sequence that bound to the bit-field as if it were a real lvalue. Note
that we previously (and still) diagnose binding of non-const
references to bit-fields, as we should.
There's no real way to test that this code is correct, since reference
binding does not *currently* have any representation in the AST. This
fix should make it easier for that to happen, so I've verified this
fix with...
Added InitializationSequence::dump(), to print an initialization
sequence for debugging purposes.
llvm-svn: 94826
Argyrios Kyrtzidis