| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointers thereof) to their corresponding non-noreturn function
types. This conversion is considered an exact match for
overload-resolution purposes. Note that we are a little more strict
that GCC is, because we encode noreturn in the type system, but that's
a Good Thing (TM) because it does not allow us to pretend that
potentially-returning function pointers are non-returning function
pointers.
Fxies PR5620.
llvm-svn: 90913
|
|
|
|
|
|
|
|
|
|
|
| |
overloaded-operator resolution is wildly untested, but the parallel code for
methods seems to satisfy some trivial tests.
Also change some overload-resolution APIs to take a type instead of an expression,
which lets us avoid creating a spurious CXXThisExpr when resolving implicit
member accesses.
llvm-svn: 90410
|
|
|
|
| |
llvm-svn: 90313
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implicit member access to a specific declaration, go ahead and create
it as a DeclRefExpr or a MemberExpr (with implicit CXXThisExpr base) as
appropriate. Otherwise, create an UnresolvedMemberExpr or
DependentScopeMemberExpr with a null base expression.
By representing implicit accesses directly in the AST, we get the ability
to correctly delay the decision about whether it's actually an instance
member access or not until resolution is complete. This permits us
to correctly avoid diagnosing the 'problem' of 'MyType::foo()'
where the relationship to the type isn't really known until instantiation.
llvm-svn: 90266
|
|
|
|
|
|
|
|
| |
Create a new UnresolvedMemberExpr for these lookups. Assorted hackery
around qualified member expressions; this will all go away when we
implement the correct (i.e. extremely delayed) implicit-member semantics.
llvm-svn: 90161
|
|
|
|
| |
llvm-svn: 90044
|
|
|
|
|
|
|
|
|
|
|
|
| |
DependentScopeDeclRefExpr support storing templateids. Unite the common
code paths between ActOnDeclarationNameExpr and ActOnTemplateIdExpr.
This gets us to a point where we don't need to store function templates in
the AST using TemplateNames, which is critical to ripping out OverloadedFunction.
Also resolves a few FIXMEs.
llvm-svn: 89785
|
|
|
|
|
|
| |
PR5541
llvm-svn: 89652
|
|
|
|
|
|
| |
DeclRefExprs
llvm-svn: 89649
|
|
|
|
|
|
|
|
|
|
| |
locations" into
a new class. Use it pervasively throughout Sema.
My fingers hurt.
llvm-svn: 89638
|
|
|
|
|
|
| |
this information through lookup rather than rederiving it.
llvm-svn: 89570
|
|
|
|
|
|
| |
threading that state.
llvm-svn: 89557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into pretty much everything about overload resolution in order to wean
BuildDeclarationNameExpr off LookupResult::getAsSingleDecl(). Replace
UnresolvedFunctionNameExpr with UnresolvedLookupExpr, which generalizes the
idea of a non-member lookup that we haven't totally resolved yet, whether by
overloading, argument-dependent lookup, or (eventually) the presence of
a function template in the lookup results.
Incidentally fixes a problem with argument-dependent lookup where we were
still performing ADL even when the lookup results contained something from
a block scope.
Incidentally improves a diagnostic when using an ObjC ivar from a class method.
This just fell out from rewriting BuildDeclarationNameExpr's interaction with
lookup, and I'm too apathetic to break it out.
The only remaining uses of OverloadedFunctionDecl that I know of are in
TemplateName and MemberExpr.
llvm-svn: 89544
|
|
|
|
|
|
|
| |
than tweaking existing ASTs, since we were (*gasp*) stomping on ASTs
within templates. I'm glad we found this little stick of TNT early...
llvm-svn: 89475
|
|
|
|
|
|
| |
overloadable. Compound assignment may be overloaded as a non-member, and anyway the overload resolution is necessary because it triggers implicit (used-defined) conversions. Fixes PR5512, but not really the deeper issues lurking. Those are standard defects.
llvm-svn: 89268
|
|
|
|
|
|
|
| |
rather than NamedDecl*. This is a major step towards eliminating
OverloadedFunctionDecl.
llvm-svn: 89263
|
|
|
|
|
|
| |
const and/or volatile objects. Fixes PR5548.
llvm-svn: 89244
|
|
|
|
|
|
| |
array subscript and arithmetic. Fixes PR5546.
llvm-svn: 89242
|
|
|
|
|
|
| |
lack of viable convesion functions.
llvm-svn: 89216
|
|
|
|
| |
llvm-svn: 89199
|
|
|
|
| |
llvm-svn: 89192
|
|
|
|
|
|
| |
operator->.
llvm-svn: 89180
|
|
|
|
| |
llvm-svn: 89141
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
constructor. Make sure that such declarations can never be formed.
llvm-svn: 88718
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
| |
ArrayType>()) does not instantiate. Update all callers that used this
unsafe feature to use the appropriate ASTContext::getAs*ArrayType method.
llvm-svn: 86596
|
|
|
|
|
|
| |
its element type. Fixes pr5432.
llvm-svn: 86587
|
|
|
|
|
|
| |
overloaded operator().
llvm-svn: 86581
|
|
|
|
| |
llvm-svn: 86387
|
|
|
|
|
|
|
| |
It has to do with vararg constructors used as conversion
functions. Code gen needs work. This is WIP.
llvm-svn: 86207
|
|
|
|
|
|
| |
pointers. Otherwise, subscripting an array leads to no candidates at all. Fixes PR5360.
llvm-svn: 86140
|
|
|
|
|
|
|
|
|
|
|
|
| |
(without complaining if it fails) to get proper semantics: reference
binding with a derived-to-base conversion and the enumeration of
constructors for user-defined conversions. There are probably more
cases to fix, but my prior attempt at statically ensuring that
complete-type checking always happens failed. Perhaps I'll try again.
With this change, Clang can parse include/llvm/*.h!
llvm-svn: 86129
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
still be dependent or invoke an overloaded operator. Previously, we
only supported builtin operators.
BinaryOperator/CompoundAssignOperator didn't have this issue because
we always built a CXXOperatorCallExpr node, even when name lookup
didn't find any functions to save until instantiation time. Now, that
code builds a BinaryOperator or CompoundAssignOperator rather than a
CXXOperatorCallExpr, to save some space.
llvm-svn: 86087
|
|
|
|
| |
llvm-svn: 86079
|
|
|
|
|
|
| |
derived-to-base pointer case
llvm-svn: 85532
|
|
|
|
| |
llvm-svn: 85524
|
|
|
|
|
|
|
| |
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
llvm-svn: 85500
|
|
|
|
|
|
| |
refers to a RecordType. Add assertions or conditions as appropriate. This fixes another crash in the Apache stdlib vector.
llvm-svn: 85055
|
|
|
|
|
|
|
| |
address of a member template when explicit template arguments are
provided.
llvm-svn: 84991
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so that we maintain better source information after template argument
deduction and overloading resolves down to a specific
declaration. Found and dealt with a few more cases that
FixOverloadedFunctionReference didn't cope with.
(Finally) added a test case that puts together this change with the
DeclRefExpr change to (optionally) include nested-name-specifiers and
explicit template argument lists.
llvm-svn: 84974
|
|
|
|
|
|
| |
argument-dependent lookup too. This fixes PR5244.
llvm-svn: 84963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qualified reference to a declaration that is not a non-static data
member or non-static member function, e.g.,
namespace N { int i; }
int j = N::i;
Instead, extend DeclRefExpr to optionally store the qualifier. Most
clients won't see or care about the difference (since
QualifierDeclRefExpr inherited DeclRefExpr). However, this reduces the
number of top-level expression types that clients need to cope with,
brings the implementation of DeclRefExpr into line with MemberExpr,
and simplifies and unifies our handling of declaration references.
Extended DeclRefExpr to (optionally) store explicitly-specified
template arguments. This occurs when naming a declaration via a
template-id (which will be stored in a TemplateIdRefExpr) that,
following template argument deduction and (possibly) overload
resolution, is replaced with a DeclRefExpr that refers to a template
specialization but maintains the template arguments as written.
llvm-svn: 84962
|