| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
@class.
llvm-svn: 89170
|
|
|
|
| |
llvm-svn: 89168
|
|
|
|
|
|
| |
referring to message sends
llvm-svn: 89164
|
|
|
|
|
|
|
|
|
| |
code to find and add Objective-C methods (starting at an
ObjCContainerDecl) into a single, static function. Also, make sure
that we search into the implementations of classes and categories to
find even more methods.
llvm-svn: 89163
|
|
|
|
|
|
| |
Action::ActOnForwardClassDeclaration().
llvm-svn: 89162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
current DeclContext. These "imaginary" declarations pose issues for
clients searching DeclContext for actual declarations. Instead,
register them for name lookup, and add the ObjCInterfaceDecl later to
the DeclContext when we hit an actual @interface declaration.
This also fixes a bug where the invariant that the Decls in a
DeclContext are sorted in order of their appearance is no longer
violated. What could happen is that an @class causes an
ObjCInterfaceDecl to get added first to the DeclContext, then the
ObjCClassDecl itself is added, and then later the SourceLocation of
the ObjCInterfaceDecl is updated with the correct location (which is
later in the file). This breaks an assumed invariant in
ResolveLocation.cpp (and possibly other clients).
llvm-svn: 89160
|
|
|
|
| |
llvm-svn: 89141
|
|
|
|
|
|
| |
(Radar 6815425).
llvm-svn: 89124
|
|
|
|
| |
llvm-svn: 89113
|
|
|
|
| |
llvm-svn: 89112
|
|
|
|
| |
llvm-svn: 89107
|
|
|
|
|
|
| |
placeholder arguments for Objective-C message sends.
llvm-svn: 89103
|
|
|
|
| |
llvm-svn: 89102
|
|
|
|
|
|
| |
lookup all in a night.
llvm-svn: 89089
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations);
strip the sugar off in getFoundDecl() and getAsSingleDecl(), but leave it on for
clients like overload resolution who want to use the iterators.
Refactor a few pieces of overload resolution to strip off using declarations in
a single place. Don't do anything useful with the extra context knowledge yet.
llvm-svn: 89061
|
|
|
|
| |
llvm-svn: 89051
|
|
|
|
|
|
|
|
| |
Also, make the "don't know how to instantiate a particular kind of
declaration" diagnostic nicer, so we don't have to trap Clang in a
debugger to figure out what went wrong.
llvm-svn: 89050
|
|
|
|
|
|
|
| |
decl, create shadow declarations and put them in scope like normal.
Work in progress.
llvm-svn: 89048
|
|
|
|
|
|
| |
be complete.
llvm-svn: 89042
|
|
|
|
|
|
| |
destructors. Also fix PR5529.
llvm-svn: 89034
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LookupResult RAII powers to diagnose ambiguity in the results. Other diagnostics
(e.g. access control and deprecation) will be moved to automatically trigger
during lookup as part of this same mechanism.
This abstraction makes it much easier to encapsulate aliasing declarations
(e.g. using declarations) inside the lookup system: eventually, lookup will
just produce the aliases in the LookupResult, and the standard access methods
will naturally strip the aliases off.
llvm-svn: 89027
|
|
|
|
| |
llvm-svn: 89023
|
|
|
|
|
|
| |
with a trivial constructor.
llvm-svn: 88990
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sugared types. The basic problem is that our qualifier accessors
(getQualifiers, getCVRQualifiers, isConstQualified, etc.) only look at
the current QualType and not at any qualifiers that come from sugared
types, meaning that we won't see these qualifiers through, e.g.,
typedefs:
typedef const int CInt;
typedef CInt Self;
Self.isConstQualified() currently returns false!
Various bugs (e.g., PR5383) have cropped up all over the front end due
to such problems. I'm addressing this problem by splitting each
qualifier accessor into two versions:
- the "local" version only returns qualifiers on this particular
QualType instance
- the "normal" version that will eventually combine qualifiers from this
QualType instance with the qualifiers on the canonical type to
produce the full set of qualifiers.
This commit adds the local versions and switches a few callers from
the "normal" version (e.g., isConstQualified) over to the "local"
version (e.g., isLocalConstQualified) when that is the right thing to
do, e.g., because we're printing or serializing the qualifiers. Also,
switch a bunch of
Context.getCanonicalType(T1).getUnqualifiedType() == Context.getCanonicalType(T2).getQualifiedType()
expressions over to
Context.hasSameUnqualifiedType(T1, T2)
llvm-svn: 88969
|
|
|
|
|
|
| |
Get CVR qualifiers from canonical types. Traverse collected qualifiers in reverse order on rebuilding the pointer, so that we don't swap inner and outer qualifiers. That last one fixes PR5509.
llvm-svn: 88960
|
|
|
|
|
|
| |
treat it as a unary operator.
llvm-svn: 88938
|
|
|
|
|
|
|
|
| |
gracefully, on par with gcc, by: Issuing a warning,
doing final sematinc check of its definitions and generating
its meta-data.
llvm-svn: 88934
|
|
|
|
| |
llvm-svn: 88893
|
|
|
|
| |
llvm-svn: 88877
|
|
|
|
| |
llvm-svn: 88859
|
|
|
|
| |
llvm-svn: 88858
|
|
|
|
|
|
| |
function.
llvm-svn: 88857
|
|
|
|
|
|
| |
function we should not look for a deallocation function in the global scope.
llvm-svn: 88851
|
|
|
|
|
|
|
|
|
|
| |
that we're dealing with canonical types like the documentation say
(yay, CanQualType). Alas, this is another instance where using
getQualifiers() on a non-canonical QualType got us in trouble.
Good news: with this fix, Clang can now parse all of its own headers!
llvm-svn: 88848
|
|
|
|
|
|
| |
initializers as used
llvm-svn: 88847
|
|
|
|
|
|
|
|
|
| |
set, expand overloaded function declarations. Long-term, this should
actually be done by the name-lookup code rather than here, but this
part of the code (involving using declarations) is getting a makeover
now and the test-case is useful.
llvm-svn: 88846
|
|
|
|
|
|
|
|
|
| |
type, use full qualified name lookup rather than the poking the
declaration context directly. This makes sure that we see operator()'s
in superclasses. Also, move the complete-type check before this name
lookup.
llvm-svn: 88842
|
|
|
|
|
|
| |
clear out any remaining temporaries so they aren't seen later.
llvm-svn: 88834
|
|
|
|
| |
llvm-svn: 88811
|
|
|
|
|
|
|
|
|
| |
reference. CheckReferenceInit already inserts implicit casts to the necessary types. This fixes an assertion in CodeGen for some casts and brings a fix for PR5453 close, if I understand that bug correctly.
- Also, perform calculated implicit cast sequences if they're determined to work. This finally diagnoses static_cast to ambiguous or implicit bases and fixes two long-standing fixmes in the test case. For the C-style cast, this requires propagating the access check suppression pretty deep into other functions.
- Pass the expressions for TryStaticCast and TryStaticImplicitCast by reference. This should lead to a better AST being emitted for such casts, and also fixes a memory leak, because CheckReferenceInit and PerformImplicitConversion wrap the node passed to them. These wrappers were previously lost.
llvm-svn: 88809
|
|
|
|
|
|
| |
when there are more parameters in the prototype than arguments to the call.
llvm-svn: 88759
|
|
|
|
|
|
| |
definitions just because the type happens to be an array type.
llvm-svn: 88752
|
|
|
|
|
|
|
|
| |
cast) that is converting to a class type, enumerate its constructors
as in any other direct initialization. This ensures that we get the
proper conversion sequence.
llvm-svn: 88751
|
|
|
|
|
|
| |
please review.
llvm-svn: 88747
|
|
|
|
|
|
|
|
|
|
|
|
| |
like a copy constructor to the overload set, just ignore it. This
ensures that we don't try to use such a constructor as a copy
constructor *without* triggering diagnostics at the point of
declaration.
Note that we *do* diagnose such copy constructors when explicitly
written by the user (e.g., as an explicit specialization).
llvm-svn: 88733
|
|
|
|
|
|
| |
constructor-template-as-copy-constructor issue. Big thanks to John for finding this
llvm-svn: 88724
|
|
|
|
|
|
| |
template argument.
llvm-svn: 88722
|
|
|
|
|
|
| |
constructor. Make sure that such declarations can never be formed.
llvm-svn: 88718
|
|
|
|
| |
llvm-svn: 88687
|
|
|
|
| |
llvm-svn: 88679
|