A::f
that occurs within a non-static member function with a type-dependent
"this", don't consider this to be a case for introduction of an
implicit "(*this)." to refer to a specific member function unless we
know (at template definition time) that A is a base class of *this.
There is some disagreement here between GCC, EDG, and Clang about the
handling of this case. I believe that Clang now has the correct,
literal interpretation of the standard, but have asked for
clarification (c++std-core-15483).
llvm-svn: 89425
appropriate lookup and simply can't resolve the referrent yet, and
"dependent scope" expressions, where we can't do the lookup yet because the
entity we need to look into is a dependent type.
llvm-svn: 89402
incomplete array initialization, where we have the following in a
template:
int a[] = { 1, 2, something-value-dependent };
// ...
sizeof(a);
The type of "a" appears to be a non-dependent IncompleteArrayType, but
treating it as such makes the sizeof(a) fail at template definition
time. We now correctly handle this by morphing the IncompleteArrayType
into a DependentSizedArrayType with a NULL expression, indicating that
its size has no corresponding expression (and, therefore, the type is
distinct from others).
llvm-svn: 89366
provide completion results before each keyword argument, e.g.,
[foo Method:arg WithArg1:arg1 WithArg2:arg2]
We now complete before "WithArg1" and before "WithArg2", in addition
to completing before "Method".
llvm-svn: 89290
declaration by providing patterns for "getter = <method>" and "setter
= <method>". As part of this, invented a new "pattern" result kind
that is merely a semantic string. The "pattern" result kind should
help with other kinds of code templates.
llvm-svn: 89277
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.
llvm-svn: 89184
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
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
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
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
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
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
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
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
- 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
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
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
a class type from itself or a derived class thereof, enumerate
constructors and permit user-defined conversions to the arguments of
those constructors. This fixes the wacky implicit conversion sequence
used in std::auto_ptr's lame emulation of move semantics.
llvm-svn: 88670
instantiation), be sure to finish the expression statement by
providing a FullExprArg, making sure that temporaries get
destroyed. Fixes an obscure failure when parsing
llvm/LinkAllPasses.h.
llvm-svn: 88668
- Provide Sema in callbacks, instead of requiring it in constructor. This
eliminates the need for a factory function. Clients now just pass the object
to consume the results in directly.
- CodeCompleteConsumer is cheap to construct, so building it whenever we are
doing code completion is reasonable.
Doug, please review.
llvm-svn: 87099
1. For
A f() {
return A();
}
we were incorrectly calling the A destructor on the returned object.
2. For
void f(A);
void g() {
A a;
f(a);
}
we were incorrectly not calling the copy constructor.
llvm-svn: 87082
non-type template parameters or constants of pointer-to-member
type. Once checked, be sure to retain those pointer-to-member
constants as expressions if they are dependent, or as declarations if
they are not dependent.
llvm-svn: 87010
member type (e.g., T Class::*Member), build a pointer-to-member
constant expression. Previously, we we just building a simple
declaration reference expression, which meant that the expression was
not treated as a pointer to member.
llvm-svn: 87000
in "if" statements like:
if (CanQual<ReferenceType> RefType = T.getAs<ReferenceType>())
Thanks to Clang for pointing out this mistake :)
llvm-svn: 86995
- Comparing template parameter lists to determine if we have a redeclaration
- Comparing template parameter lists to determine if we have equivalent
template template parameters
- Comparing template parameter lists to determine whether a template
template argument is valid for a given template template parameter.
Previously, we did not distinguish between the last two cases, which
got us into trouble when we were looking for exact type matches
between the types of non-type template parameters that were dependent
types. Now we do, so we properly delay checking of template template
arguments until instantiation time.
Also, fix an accidental fall-through in a case statement that was
causing crashes.
llvm-svn: 86992
Douglas Gregor