| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
access. Fixes an assertion.
Fixes rdar://problem/7927811. Too lazy to reduce a test case.
llvm-svn: 102776
|
| |
|
|
|
|
| |
constant expression in C.
llvm-svn: 102762
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
ObjCMethodDecl::isVariadic().
Do some minor refactoring along the way.
llvm-svn: 102635
|
| |
|
|
|
|
|
|
| |
IEEE-754, e.g.,
NAN != NAN ? 1 : 0 should return 1. Also fix the case for complex.
llvm-svn: 102598
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
compatibility of", it is breaking the builds of quite a few projects (emacs, dovecot, gnutar, bison).
llvm-svn: 102501
|
| |
|
|
| |
llvm-svn: 102498
|
| |
|
|
| |
llvm-svn: 102465
|
| |
|
|
|
|
|
|
|
| |
function types.
This could potentially have unexpected side-effects, so look here if there are
new regressions.
llvm-svn: 102464
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 102447
|
| |
|
|
|
|
|
| |
from AST, consider ivar array of objects
(per Doug's comment).
llvm-svn: 102446
|
| |
|
|
| |
llvm-svn: 102445
|
| |
|
|
| |
llvm-svn: 102420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
constructors or destructors, not used yet.
llvm-svn: 102403
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
@catch a VarDecl. The dynamic type is still a ParmVarDecl, but that
will change soon. No effective functionality change.
llvm-svn: 102341
|
| |
|
|
| |
llvm-svn: 102259
|
| |
|
|
| |
llvm-svn: 102258
|
| |
|
|
| |
llvm-svn: 102249
|
| |
|
|
|
|
| |
CXXBaseSpecifierArray. More to come.
llvm-svn: 102245
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 102218
|
| |
|
|
| |
llvm-svn: 102211
|
| |
|
|
| |
llvm-svn: 102208
|
| |
|
|
|
|
| |
two bugfixes which fix selfhost and (hopefully) the nightly tests.
llvm-svn: 102198
|
| |
|
|
|
|
| |
NeXt's -fno-constant-cfstrings - wip.
llvm-svn: 102189
|
| |
|
|
|
|
| |
variants. This fixes neon inline asm which my patch for PR6780 broke.
llvm-svn: 102181
|
| |
|
|
|
|
| |
same", which seems to break most C++ nightly test apps.
llvm-svn: 102174
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 102145
|
| |
|
|
|
|
|
| |
aren't and never were used. There's a gap in the bit pattern for IDNS
now, but I'm sure *someone* will fill it.
llvm-svn: 102143
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
the alignment is a power of 2, even in the esoteric case of a
vector element which does not have a power-of-2 sizeof value.
llvm-svn: 102036
|
| |
|
|
| |
llvm-svn: 101994
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 101953
|
| |
|
|
|
|
|
|
| |
into ContentCache::getBuffer. This allows it to produce
diagnostics on the broken #include line instead of without a
location.
llvm-svn: 101939
|
| |
|
|
| |
llvm-svn: 101912
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
-fdump-record-layouts.
llvm-svn: 101815
|
| |
|
|
| |
llvm-svn: 101786
|