cannot be converted.
This is in preparation for overload resolution of initializer lists.
Currently, you will always get this message when you try to pass an init
list to an overloaded function.
llvm-svn: 140461
builds a semantic (structured) initializer list, just reports on whether it can match
the given list to the target type.
Use this mode for doing init list checking in the initial step of initialization, which
will eventually allow us to do overload resolution based on the outcome.
llvm-svn: 140457
For example:
void f(float);
void f(int);
int main {
long a;
f(a);
}
Here, MSVC will call f(int) instead of generating a compile error as clang will do in standard mode.
This fixes a few errors when parsing MFC code with clang.
llvm-svn: 140007
converting to an arbitrary Objective-C pointer type is. Without
significantly re-implementing anything, change the API to reflect this,
and as a minor optimization, strip the pointer conversion off before
potentially building it.
Mostly, this removes a really bizarre-looking bit of code from
BuildInstanceMessage.
llvm-svn: 139354
than conversions of C pointers to ObjC pointers. In order to ensure that
we've caught every case, add asserts to CastExpr that strictly determine
which cast kind is used for which kind of bit cast.
llvm-svn: 139352
Change TypoCorrection to store a set of NamedDecls instead of a single
NamedDecl. Also add initial support for performing function overload
resolution to Sema::DiagnoseEmptyLookup.
llvm-svn: 136807
considering explicit conversion operators when determining surrogate
functions. Fixes PR10453. Note that there are a few test cases where
Clang is still wrong because it does not implement DR899; see PR10456.
Patch by Jonathan Sauer!
llvm-svn: 135857
IsIntegralPromotion should consider the signedness of FromType when
calculating promotions. This, as of now, cannot be exercised on any
platform so there is no corresponding test.
llvm-svn: 135803
of a single if block. This is really annoying to track down and test.
Silly changes to the test case caused it to stop showing up. I wish
there were a more concrete way of asserting that a note attaches to the
intended diagnostic.
This fixes PR10195.
llvm-svn: 133907
deducing template parameter types. Recently Clang began enforcing the
more strict checking that the argument type and the deduced function
parameter type (after substitution) match, but that only consideres
qualification conversions.
One problem with this patch is that we check noreturn conversions and
qualification conversions independently. If a valid conversion would
require *both*, perhaps interleaved with each other, it will be
rejected. If this actually occurs (I'm not yet sure it does) and is in
fact a problem (I'm not yet sure it is), there is a FIXME to implement
more intelligent conversion checking.
However, this step at least allows Clang to resume accepting valid code
we're seeing in the wild.
llvm-svn: 133327
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
namespace set algorithm (re-)introduced. We may not have seen the 'std'
namespace, but we should still suggested associated namespaces. Easy
fix, but a bit annoying to test.
llvm-svn: 132744
compared even when one is a reference binding and the other is not
(<rdar://problem/9173984>), but the definition of an identity sequence
does not involve lvalue-to-rvalue adjustments (PR9507). Fix both
inter-related issues.
llvm-svn: 132660
minor issues along the way:
- Non-type template parameters of type 'std::nullptr_t' were not
permitted.
- We didn't properly introduce built-in operators for nullptr ==,
!=, <, <=, >=, or > as candidate functions .
To my knowledge, there's only one (minor but annoying) part of nullptr
that hasn't been implemented: catching a thrown 'nullptr' as a pointer
or pointer-to-member, per C++0x [except.handle]p4.
llvm-svn: 131813
bit by allowing __weak and __strong to be added/dropped as part of
implicit conversions (qualification conversions in C++). A little
history: GCC lets one add/remove/change GC qualifiers just about
anywhere, implicitly. Clang did roughly the same before, but we
recently normalized the semantics of qualifiers across the board to
get a semantics that we could reason about (yay). Unfortunately, this
tightened the screws a bit too much for GC qualifiers, where it's
common to add/remove these qualifiers at will.
Overall, we're still in better shape than we were before: we don't
permit directly changing the GC qualifier (e.g., __weak -> __strong),
so type safety is improved. More importantly, we're internally
consistent in our handling of qualifiers, and the logic that allows
adding/removing GC qualifiers (but not adding/removing address
spaces!) only touches two obvious places.
Fixes <rdar://problem/9402499>.
llvm-svn: 131065
the overloading of member and non-member functions results in arity
mismatches that don't fit well into our overload-printing scheme. This
only happens for invalid code (which breaks the arity invariants for
these cases), so just suppress the diagnostic rather than inventing
anything new. Fixes <rdar://problem/9222009>.
llvm-svn: 130902
Decl actually found via name lookup & overload resolution when that Decl
is different from the ValueDecl which is actually referenced by the
expression.
This can be used by AST consumers to correctly attribute references to
the spelling location of a using declaration, and otherwise gain insight
into the name resolution performed by Clang.
The public interface to DRE is kept as narrow as possible: we provide
a getFoundDecl() which always returns a NamedDecl, either the ValueDecl
referenced or the new, more precise NamedDecl if present. This way AST
clients can code against getFoundDecl without know when exactly the AST
has a split representation.
For an example of the data this provides consider:
% cat x.cc
namespace N1 {
struct S {};
void f(const S&);
}
void test(N1::S s) {
f(s);
using N1::f;
f(s);
}
% ./bin/clang -fsyntax-only -Xclang -ast-dump x.cc
[...]
void test(N1::S s) (CompoundStmt 0x5b02010 <x.cc:5:20, line:9:1>
(CallExpr 0x5b01df0 <line:6:3, col:6> 'void'
(ImplicitCastExpr 0x5b01dd8 <col:3> 'void (*)(const struct N1::S &)' <FunctionToPointerDecay>
(DeclRefExpr 0x5b01d80 <col:3> 'void (const struct N1::S &)' lvalue Function 0x5b01a20 'f' 'void (const struct N1::S &)'))
(ImplicitCastExpr 0x5b01e20 <col:5> 'const struct N1::S' lvalue <NoOp>
(DeclRefExpr 0x5b01d58 <col:5> 'N1::S':'struct N1::S' lvalue ParmVar 0x5b01b60 's' 'N1::S':'struct N1::S')))
(DeclStmt 0x5b01ee0 <line:7:3, col:14>
0x5b01e40 "UsingN1::;")
(CallExpr 0x5b01fc8 <line:8:3, col:6> 'void'
(ImplicitCastExpr 0x5b01fb0 <col:3> 'void (*)(const struct N1::S &)' <FunctionToPointerDecay>
(DeclRefExpr 0x5b01f80 <col:3> 'void (const struct N1::S &)' lvalue Function 0x5b01a20 'f' 'void (const struct N1::S &)' (UsingShadow 0x5b01ea0 'f')))
(ImplicitCastExpr 0x5b01ff8 <col:5> 'const struct N1::S' lvalue <NoOp>
(DeclRefExpr 0x5b01f58 <col:5> 'N1::S':'struct N1::S' lvalue ParmVar 0x5b01b60 's' 'N1::S':'struct N1::S'))))
Now we can tell that the second call is 'using' (no pun intended) the using
declaration, and *which* using declaration it sees. Without this, we can
mistake calls that go through using declarations for ADL calls, and have no way
to attribute names looked up with using declarations to the appropriate
UsingDecl.
llvm-svn: 130670
non-CVR qualifiers as well as CVR qualifiers. For example, don't allow
a reference to an integer in address space 1 to bind to an integer in
address space 2.
llvm-svn: 130411
determine which is a better conversion to "void*", be sure to perform
the comparison using the safe-for-id
ASTContext::canAssignObjCInterfaces() rather than the asserts-with-id
ASTContext::canAssignObjCInterfaces().
Fixes <rdar://problem/9327203>.
llvm-svn: 130259
the qualifiers (e.g., GC qualifiers) on the type we're converting
from, rather than just blindly adopting the qualifiers of the type
we're converting to or dropping qualifiers altogether.
As an added bonus, properly diagnose GC qualifier mismatches to
eliminate a crash in the overload resolution failure diagnostics.
llvm-svn: 130255
member function, i.e. something of the form 'x.f' where 'f' is a non-static
member function. Diagnose this in the general case. Some of the new diagnostics
are probably worse than the old ones, but we now get this right much more
universally, and there's certainly room for improvement in the diagnostics.
llvm-svn: 130239
Objective-C pointer to void* as a "conversion to void*". This allows
us to prefer an Objective-C object pointer conversion to a superclass
object pointer over an Objective-C object pointer conversion to
cv-void*. Fixes PR9735.
llvm-svn: 129603
type rather than just the literal 'false'. This begins fixing PR9612,
but the message is now wrong. WIP, the cleanup of the messaging is next.
llvm-svn: 129204
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
when the resolution took place due to a single template specialization
being named with an explicit template argument list. In this case, the
"resolution" doesn't take into account the target type at all, and
therefore can take place for functions, static member functions, and
*non-static* member functions. The latter weren't being properly checked
and their proper form enforced in this scenario. We now do so.
The result of this last form slipping through was some confusing logic
in IsStandardConversion handling of these resolved address-of
expressions which eventually exploded in an assert. Simplify this logic
a bit and add some more aggressive asserts to catch improperly formed
expressions getting into this routine.
Finally add systematic testing of member functions, both static and
non-static, in the various forms they can take. One of these is
essentially PR9563, and this commit fixes the crash in that PR. However,
the diagnostics for this are still pretty terrible. We at least are now
accepting the correct constructs and rejecting the invalid ones rather
than accepting invalid or crashing as before.
llvm-svn: 128456
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
overload, so that we actually do the resolution for full expressions
and emit more consistent, useful diagnostics. Also fixes an IRGen
crasher, where Sema wouldn't diagnose a resolvable bound member
function template-id used in a full-expression (<rdar://problem/9108698>).
llvm-svn: 127747
parameter, save the instantiated default template arguments along with
the explicitly-specified template argument list. That way, we prefer
the default template template arguments corresponding to the template
template parameter rather than those of its template template argument.
This addresses the likely direction of C++ core issue 150, and fixes
PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of
EDG and GCC.
llvm-svn: 126920
possible for these to show up due to metaprogramming both in unevaluated
contexts and compile-time dead branches.
Those aren't the bugs we're looking for.
llvm-svn: 126739
UnresolvedLookupExpr and UnresolvedMemberExpr.
Also, improve the computation that checks whether the base of a member
expression (either unresolved or dependent-scoped) is implicit. The
previous check didn't cover all of the cases we use in our
representation, which threw off source-location information for these
expressions (which, in turn, caused some breakage in libclang's token
annotation).
llvm-svn: 126681
marking selected overloads into the callers. This allows a few callers
to skip it altogether (they would have anyways because they weren't
interested in successful overloads) or defer until after further checks
take place much like the check required for PR9323 to avoid marking
unused copy constructors.
llvm-svn: 126503
declarations as referenced when in fact we're not going to even form
a call in the AST. This is significant because we attempt to allow as an
extension classes with intentionally private and undefined copy
constructors to have temporaries bound to references, and so shouldn't
warn about the lack of definition for that copy constructor when the
class is internal.
Doug, John wasn't really satisfied with the presence of overloading at
all. This is a stop-gap and there may be a better solution. If you can
give me some hints for how you'd prefer to see this solved, I'll happily
switch things over.
llvm-svn: 126480
nested-name-specifiers throughout the parser, and provide a new class
(NestedNameSpecifierLoc) that contains a nested-name-specifier along
with its type-source information.
Right now, this information is completely useless, because we don't
actually store the source-location information anywhere in the
AST. Call this Step 1/N.
llvm-svn: 126391
includes explicitly-specified template arguments) to a function
template specialization in cases where no deduction is performed or
deduction fails. Patch by Faisal Vali, fixes PR7505!
llvm-svn: 126048
conversions (<rdar://problem/8592139>) for overload resolution. The
conversion ranking mirrors C++'s conversion ranking fairly closely,
except that we use a same pseudo-subtyping relationship employed by
Objective-C pointer assignment rather than simple checking
derived-to-base conversions. This change covers:
- Conversions to pointers to a specific object type are better than
conversions to 'id', 'Class', qualified 'id', or qualified 'Class'
(note: GCC doesn't perform this ranking, but it matches C++'s rules
for ranking conversions to void*).
- Conversions to qualified 'id' or qualified 'Class' are better than
conversions to 'id' or 'Class', respectively.
- When two conversion sequences convert to the same type, rank the
conversions based on the relationship between the types we're
converting from.
- When two conversion sequences convert from the same non-id,
non-Class type, rank the conversions based on the relationship of
the types we're converting to. (note: GCC allows this ranking even
when converting from 'id', which is extremeley dangerous).
llvm-svn: 124591
derived-to-base cast that also casts away constness (one of the cases
for static_cast followed by const_cast) would be treated as a bit-cast
rather than a derived-to-base class, causing miscompiles and
heartburn.
Fixes <rdar://problem/8913298>.
llvm-svn: 124340
overload a function without a ref-qualifier (C++0x
[over.load]p2). This, apparently, completes the implementation of
rvalue references for *this.
llvm-svn: 124321
reference binding is for the implicit object parameter of a member
function with a ref-qualifier. My previous comment, that we didn't
need to track this explicitly, was wrong: we do in fact get
rvalue-references-prefer-rvalues overloading with ref-qualifiers.
llvm-svn: 124313
the presence and form of a ref-qualifier. Note that we do *not* yet
implement the restriction in C++0x [over.load]p2 that requires either
all non-static functions with a given parameter-type-list to have a
ref-qualifier or none of them to have a ref-qualifier.
llvm-svn: 124297
for reference binding (C++ [over.rank.ics]p3b1sb4), so that we prefer
the binding of an lvalue reference to a function lvalue over the
binding of an rvalue reference. This change resolves the ambiguity
with std::forward and lvalue references to function types in a way
that seems consistent with the original rvalue references proposal.
My proposed wording for this change is shown in
isBetterReferenceBindingKind(); we'll try to get this change adopted
in the C++0x working paper as well.
llvm-svn: 124236
(C++0x [over.ics.rank]p3) when one binding is an lvalue reference and
the other is an rvalue reference that binds to an rvalue. In
particular, we were using the predict "is an rvalue reference" rather
than "is an rvalue reference that binds to an rvalue", which was
incorrect in the one case where an rvalue reference can bind to an
lvalue: function references.
This particular issue cropped up with std::forward, where Clang was
picking an std::forward overload while forwarding an (lvalue)
reference to a function. However (and unfortunately!), the right
answer for this code is that the call to std::forward is
ambiguous. Clang now gets that right, but we need to revisit the
std::forward implementation in libc++.
llvm-svn: 124216
implementation used by overload resolution to support rvalue
references. The original commits caused PR9026 and some
hard-to-reproduce self-host breakage.
The only (crucial!) difference between this commit and the previous
commits is that we now properly check the SuppressUserConversions flag
before attempting to perform a second user-defined conversion in
reference binding, breaking the infinite recursion chain of
user-defined conversions.
Rvalue references should be working a bit better now.
llvm-svn: 124121
resolution to match the latest C++0x working paper's semantics. The
implementation now matching up with the reference-binding
implementation used for initialization.
llvm-svn: 123977
call (C++0x [temp.deduct.call]p3).
As part of this, start improving the reference-binding implementation
used in the computation of implicit conversion sequences (for overload
resolution) to reflect C++0x semantics. It still needs more work and
testing, of course.
llvm-svn: 123966
outermost array types and not on the element type. Move the CanonicalType
member from Type to ExtQualsTypeCommonBase; the canonical type on an ExtQuals
node includes the qualifiers on the ExtQuals. Assorted optimizations enabled
by this change.
getQualifiers(), hasQualifiers(), etc. should all now implicitly look through
array types.
llvm-svn: 123817
For example:
class A{
public:
A& operator=(const A& that) {
if (this != &that) {
this->A::~A();
this->A::A(that); // <=== explicit constructor call.
}
return *this;
}
};
More work will be needed to support an explicit call to a template constructor.
llvm-svn: 123735
number of explicit call arguments. This actually fixes an erroneous
test for [temp.deduct.partial]p11, where we were considering
parameters corresponding to arguments beyond those that were
explicitly provided.
llvm-svn: 123244
template whose last parameter is a parameter pack. This allows us to
form a call to, e.g.,
template<typename ...Args1, typename ...Args2>
void f(std::pair<Args1, Args2> ...pairs);
given zero or more instances of "pair".
llvm-svn: 122973
whether the expression contains an unexpanded parameter pack, in the
same vein as the changes to the Type hierarchy. Compute this bit
within all of the Expr subclasses.
This change required a bunch of reshuffling of dependency
calculations, mainly to consolidate them inside the constructors and
to fuse multiple loops that iterate over arguments to determine type
dependence, value dependence, and (now) containment of unexpanded
parameter packs.
Again, testing is painfully sparse, because all of the diagnostics
will change and it is more important to test the to-be-written visitor
that collects unexpanded parameter packs.
llvm-svn: 121831
cases. First, omit all builtin overloads when no non-record type is in the set
of candidate types. Second, avoid arithmetic type overloads for non-arithmetic
or enumeral types (counting vector types as arithmetic due to Clang
extensions). When heavily using constructs such as STL's '<<' based stream
logging, this can have a significant impact. One logging-heavy test case's
compile time dropped by 10% with this. Self-host shows 1-2% improvement in
compile time, but that's likely in the noise.
llvm-svn: 121665
type. Localize all of the logic within a single function rather than spreading
it throughout the class.
Also fixes a buglet where we failed to check for a RHS arithmetic type wider
than the LHS and return its canonical type. I've yet to produce a test case
that breaks because of this, but it was spotted by inspection by folks on the
IRC channel and is obviously correct now.
llvm-svn: 121633
user-defined operator overloads on the same enumeral types to the one place
where it is used.
In theory this removes wasted computation from several paths through this code,
but I'm not aware of a case where it actually matters. This is mostly for
cleanliness.
llvm-svn: 121630
others have another ordering they would prefer, I'm all ears, but this one made
it much easier for me to find the group of operators I'm interested in.
llvm-svn: 121629
candidate set. This breaks apart a huge switch + goto system into distinct
methods on a class. It also places the current mess of tables and other static
state used in the process within that class.
This is still a work in progress. I did a few simplifications that jumped out
at me as I went, but I plan to iterate on this a bit before it's truly clean.
However, this is easily the most invasive chunk. I benchmarked it on
all-std-headers.cpp and an internal testcase that has a major hotspot in
overload resolution and saw no real performance impact.
llvm-svn: 121623
space better. Remove this reference. To make that work, change some APIs
(most importantly, getDesugaredType()) to take an ASTContext& if they
need to return a QualType. Simultaneously, diminish the need to return a
QualType by introducing some useful APIs on SplitQualType, which is
just a std::pair<const Type *, Qualifiers>.
llvm-svn: 121478
cv-qualification conversions. More specifically, there's an implicit
cv-qualification conversion (even one that drops qualifiers) when
converting to 'id' or qualified 'id'. Fixes <rdar://problem/8734046>.
llvm-svn: 121047
conversions. Previously, we would end up collapsing qualification
conversions into the Objective-C pointer conversion step, including
(possibly) stripping qualifiers that shouldn't be removed.
This generalizes BuildSimilarlyQualifiedPointerType() to also work on
Objective-C object pointers, then eliminates the (redundant, not
totally correct) BuildSimilarlyQualifiedObjCObjectPointerType()
function.
Fixes <rdar://problem/8714395>.
llvm-svn: 120607
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
(while computing user conversion sequences), make sure that a result
of class type is a complete class type. Had we gone through
ActOnCallExpr, this would have happened when we built the CallExpr.
Fixes PR8425.
llvm-svn: 119005
promoted arithmetic types for which builtin operator candidates are
emitted. A few of these need further analysis.
Removes all the uses of UsualArithmeticConversionsType except the
core function in SemaExpr.cpp.
llvm-svn: 118988
constructor template will not be used to copy a class object to a
value of its own type. We were eliminating all constructor templates
whose specializations look like a copy constructor, which eliminated
important candidates. Fixes PR8182.
llvm-svn: 118418
the sets of available conversions for the first and second arguments
separate. This is apparently the indent of C++ [over.built], and
reduces the number of overload candidates generated, eliminating some
ambiguities. Fixes PR8477.
llvm-svn: 118178
that are suppressed during template argument deduction. This change
queues diagnostics computed during template argument deduction. Then,
if the resulting function template specialization or partial
specialization is chosen by overload resolution or partial ordering
(respectively), we will emit the queued diagnostics at that point.
This addresses most of PR6784. However, the check for unnamed/local
template arguments (which existed before this change) is still only
skin-deep, and needs to be extended to look deeper into types. It must
be improved to finish PR6784.
llvm-svn: 116373
against a function type, be sure to check the type of the resulting
function template specialization against the desired function type
after substituting the deduced/defaulted template arguments. Fixes PR8196.
llvm-svn: 115086
already be determined by isCopyAssignmentOperator(), and was set too
late in the process for all clients to see the appropriate
value. Cleanup only; no functionality change.
llvm-svn: 114916
sequences for two conversion functions when in fact we are in the text
of initialization by a user-defined conversion sequences. Fixes PR8034.
llvm-svn: 113724
be a semantic requirement that a built-in overloaded operator is not
added to the overload set of there is already a user-defined
overloaded operator with the same parameter types. Fixes PR8087.
llvm-svn: 113713
with comma-separated lists. We never actually used the comma
locations, nor did we store them in the AST, but we did manage to
waste time during template instantiation to produce fake locations.
llvm-svn: 113495
For large floats/integers, APFloat/APInt will allocate memory from the heap to represent these numbers.
Unfortunately, when we use a BumpPtrAllocator to allocate IntegerLiteral/FloatingLiteral nodes the memory associated with
the APFloat/APInt values will never get freed.
I introduce the class 'APNumericStorage' which uses ASTContext's allocator for memory allocation and is used internally by FloatingLiteral/IntegerLiteral.
Fixes rdar://7637185
llvm-svn: 112361
an '&' expression from the second caller of ActOnIdExpression.
Teach template argument deduction that an overloaded id-expression
doesn't give a valid type for deduction purposes to a non-static
member function unless the expression has the correct syntactic
form.
Teach ActOnIdExpression that it shouldn't try to create implicit
member expressions for '&function', because this isn't a
permitted form of use for member functions.
Teach CheckAddressOfOperand to diagnose these more carefully.
Some of these cases aren't reachable right now because earlier
diagnostics interrupt them.
llvm-svn: 112258
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
llvm-svn: 112244
only form pointers-to-member if the expression has the appropriate
form. This avoids assertions later on on invalid code, but also
allows us to properly resolve mixed-staticity overloads.
llvm-svn: 111987
conversion a second time for a conversion candidate (with the real
acting context), because the only problems we would find are access or
ambiguity issues that won't be diagnosed until we pick this
candidate. Add a test case to prove it to myself.
llvm-svn: 111526
conversion functions as if their acting context were the class that
we're converting from (the implicit object argument's
type). Retroactively tweaking the implicit conversion sequence, as we
were trying to do before, breaks the invariants of that implicit
conversion sequence (e.g., the types and conversions don't match
up). Fixes <rdar://problem/8018274>.
llvm-svn: 111520
implicit conversion sequences. In particular, model the "standard
conversion" from a class to its own type (or a base type) directly as
a standard conversion in the normal path *without* trying to determine
if there is a valid copy constructor. This appears to match the intent
of C++ [over.best.ics]p6 and more closely matches GCC and EDG.
As part of this, model non-lvalue reference initialization via
user-defined conversion in overloading the same way we handle it in
InitializationSequence, separating the "general user-defined
conversion" and "conversion to compatible class type" cases.
The churn in the overload-call-copycon.cpp test case is because the
test case was originally wrong; it assumed that we should do more
checking for copy constructors that we actually should, which affected
overload resolution.
Fixes PR7055. Bootstrapped okay.
llvm-svn: 110773
an lvalue of another, compatible Objective-C object type (e.g., a
subclass). Introduce a new initialization sequence step kind to
describe this binding, along with a new cast kind. Fixes PR7741.
llvm-svn: 110513
This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).
Also, smoosh the CastKind into the bitfield from Expr.
Drops two words of storage from Expr in the common case of expressions
which don't need inheritance paths. Avoids a separate allocation and
another word of overhead in cases needing inheritance paths. Also has
the advantage of not leaking memory, since destructors for AST nodes are
never run.
llvm-svn: 110507
just means "not a function type", not "not a function type or void". This
changes behavior slightly, but generally in a way which accepts more code.
llvm-svn: 110303
(e.g., a call, cast, etc.), immediately adjust the expression's type
to strip cv-qualifiers off of all non-class types (in C++) or all
types (in C). This effectively extends my previous fix for PR7463,
which was restricted to calls, to other kinds of expressions within
similar characteristics. I've audited every use of
getNonReferenceType() in the code base, switching to the newly-renamed
getNonLValueExprType() where necessary.
Big thanks to Eli for pointing out just how incomplete my original fix
for PR7463 actually was. We've been handling cv-qualifiers on rvalues
wrong for a very, very long time. Fixes PR7463.
llvm-svn: 108253
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
llvm-svn: 108234
type to an integral or enumeration type in the size of an array new
expression, e.g.,
new int[ConvertibleToInt(10)];
This is a GNU and C++0x extension.
llvm-svn: 107229
have integral or enumeration type, so that we still check the contents
of the switch body. My previous patch made this worse; now we're back
to where we were previously.
llvm-svn: 107223
enumeration type out into a separate, reusable routine. The only
functionality change here is that we recover a little more
aggressively from ill-formed switch conditions.
llvm-svn: 107222
__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
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
floating-point conversions or floating-integral conversions. We
really, really, really need to make isFloatingType() and friends not
apply to vector types.
llvm-svn: 106551
introduced by using decls are hidden even if their template parameter lists
or return types differ from the "overriding" declaration.
Propagate using shadow declarations around more effectively when looking up
template-ids. Reperform lookup for template-ids in member expressions so that
access control is properly set up.
Fix some number of latent bugs involving template-ids with totally invalid
base types. You can only actually get these with a scope specifier, since
otherwise the template-id won't parse as a template-id.
Fixes PR7384.
llvm-svn: 106093
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
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
involves extending implicit conversion sequences to model vector
conversions and vector splats, along with teaching the C++ conditional
operator-checking code about vector types.
Fixes <rdar://problem/7983501>.
llvm-svn: 104081
consider "super" as a candidate whenever we're parsing an expression
within an Objective-C method in an interface that has a superclass. At
some point, we'd like to give "super" a little edge over non-local
names; that will come later.
llvm-svn: 104022
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
specific message that includes the template arguments, e.g.,
test/SemaTemplate/overload-candidates.cpp:27:20: note: candidate template
ignored: substitution failure [with T = int *]
typename T::type get_type(const T&); // expected-note{{candidate ...
^
llvm-svn: 103348
many/too few arguments, use the same diagnostic we use for arity
mismatches in non-templates (but note that it's a function template).
llvm-svn: 103341
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
ensure that we complete the type when we need to look at constructors
during reference binding.
When determining whether the two types involved in reference binding
are reference-compatible, reference-related, etc., do not complete the
type of the reference itself because it is not necessary to determine
well-formedness of the program. Complete the type that we are binding
to, since that can affect whether we know about a derived-to-base
conversion.
Re-fixes PR7080.
llvm-svn: 103283
are reference-compatible, reference-related, etc., do not complete the
type of the reference itself because it is not necessary to determine
well-formedness of the program. Complete the type that we are binding
to, since that can affect whether we know about a derived-to-base
conversion.
Fixes PR7080.
llvm-svn: 103220
typedef int functype(int, int);
functype func;
also instantiate the synthesized function parameters for the resulting
function declaration.
With this change, Boost.Wave builds and passes all of its regression
tests.
llvm-svn: 103025
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
temporary needs to be bound, bind the copy object. Otherwise, we won't
end up calling the destructor for the copy. Fixes Boost.Optional.
llvm-svn: 102290
different kinds (aka garbage). This happens if we're comparing a standard
conversion sequence to an ambiguous one which have the same KindRank.
Found by valgrind.
llvm-svn: 101717
resolution ([over.ics.ref]), we take some shortcuts required by the
standard that effectively permit binding of a const volatile reference
to an rvalue. We have to treat lightly here to avoid infinite
recursion.
Fixes PR6177.
llvm-svn: 101712
resolution. There are two sources of problems involving user-defined
conversions that this change eliminates, along with providing simpler
interfaces for checking implicit conversions:
- It eliminates a case of infinite recursion found in Boost.
- It eliminates the search for the constructor needed to copy a temporary
generated by an implicit conversion from overload
resolution. Overload resolution assumes that, if it gets a value
of the parameter's class type (or a derived class thereof), there
is a way to copy if... even if there isn't. We now model this
properly.
llvm-svn: 101680
ResolveAddressOfOverloadedFunction when asked to complain. Previously,
we had some weird handshake where ResolveAddressOfOverloadedFunction
expected its caller to handle some of the diagnostics but not others,
and yet there was no way for the caller to know which case we were
in. Eliminate this madness, fixing <rdar://problem/7765884>.
llvm-svn: 101312
for reference binding. The code attempted to handle both the
computation of the ICS and the actual conversion, but the latter is an
anachronism: we now use InitializationSequence for that.
Sema::CheckReferenceInit is now a static function TryReferenceInit
that's only use within overload resolution, and has been simplified
slightly. It still needs to be updated per C++ [over.ics.ref], by
eliminating more of the lvalue/rvalue checks.
llvm-svn: 101136
from a conversion function template specialization to one of exact
match rank. We only know how to test this in C++0x with default
function template arguments, but it's also in the C++03 spec. Fixes
PR6285.
llvm-svn: 101089
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
an object or function. Our previous checking was too lax, and ended up
allowing missing or extraneous address-of operators, among other
evils. The new checking provides better diagnostics and adheres more
closely to the standard.
Fixes PR6563 and PR6749.
llvm-svn: 100125
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
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
entity (if applicable) which was actually looked up. If a candidate was found
via a using declaration, this is the UsingShadowDecl; otherwise, if
the candidate is template specialization, this is the template; otherwise,
this is the function.
The point of this exercise is that "found declarations" are the entities
we do access control for, not their underlying declarations. Broadly speaking,
this patch fixes access control for using declarations.
There is a *lot* of redundant code calling into the overload-resolution APIs;
we really ought to clean that up.
llvm-svn: 98945
nested-name-specifier. For example, this allows member access in
diamond-shaped hierarchies like:
struct Base {
void Foo();
int Member;
};
struct D1 : public Base {};
struct D2 : public Base {};
struct Derived : public D1, public D2 { }
void Test(Derived d) {
d.Member = 17; // error: ambiguous cast from Derived to Base
d.D1::Member = 17; // error: okay, modify D1's Base's Member
}
Fixes PR5820 and <rdar://problem/7535045>. Also, eliminate some
redundancy between Sema::PerformObjectMemberConversion() and
Sema::PerformObjectArgumentInitialization() -- the latter now calls
the former.
llvm-svn: 97674
skip the object argument conversion if either of the candidates didn't
initialize it.
Fixes PR6421, which is such a very straightforward extension of PR6398 that I
should have worked it into the last test case (and therefore caught it then).
Ah well.
llvm-svn: 97135
types. Rank these conversions below other conversions. This allows overload
resolution when the only distinction is between a complex and scalar type. It
also brings the complex overload resolutin in line with GCC's.
llvm-svn: 97128
conversions. Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path. Prepare for friends.
llvm-svn: 95775
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
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
sequences, where we would occasionally determine (incorrectly) that
one standard conversion sequence was a proper subset of another when,
in fact, they contained completely incomparable conversions.
This change records the types in each step within a standard
conversion sequence, so that we can check the specific comparison
types to determine when one sequence is a proper subset of the
other. Fixes this testcase (thanks, Anders!), which was distilled from
PR6095 (also thanks to Anders).
llvm-svn: 94660
This solution relies on an O(n) scan of redeclarations, which means it might
scale poorly in crazy cases with tons of redeclarations brought in by a ton
of distinct associated namespaces. I believe that avoiding this
is not worth the common-case cost.
llvm-svn: 94530
incomplete type (or a pointer/reference to such).
The causes of this problem are different enough to justify a different "design"
for the diagnostic. Most notably, it doesn't give an operand index:
it's usually pretty obvious which operand is the problem, it adds a lot of
clutter to mention it, and the fix is usually in a different part of the file
anyway.
This is yet another diagnostic that should really have an analogue in the
non-overloaded case --- which should be much easier to write because of
the weaker space constraints.
llvm-svn: 94303
conversions. To make this work, fill out all conversions for all candidates
(but only when diagnosing overload failure). Split out a few cases from
ovl_fail_bad_conversion which didn't actually involve a failed argument
conversion.
I'm pretty sure this is not a well-founded ordering, but I'm not sure it matters.
llvm-svn: 94283
Change LookupResult to use UnresolvedSet. Also extract UnresolvedSet into its
own header and make it templated over an inline capacity.
llvm-svn: 93959
to be considering user-defined conversions in the first place.
Doug, please review; I'm not sure what we should be doing if we see a real
ambiguity in selecting a copy constructor when otherwise suppressing
user-defined conversions.
Fixes PR6014.
llvm-svn: 93365
information to feed diagnostics instead of regenerating it. Much room for
improvement here, but fixes some unfortunate problems reporting on method calls.
llvm-svn: 93316
why the candidate is non-viable. There's a lot we can do to improve this, but
it's a good start. Further improvements should probably be integrated with the
bad-initialization reporting routines.
llvm-svn: 93277
I said to myself, self, why don't you go add a couple of parameters to a method
and then fail to use them, and I thought that sounded like a pretty good idea,
so I did it.
llvm-svn: 93233
fidelity with which we note them as functions/constructors and templates
thereof. Also will be helpful when reporting bad conversions (next).
llvm-svn: 93224
sequence. Lots of small relevant changes. Fixes some serious problems with
ambiguous conversions; also possibly improves associated diagnostics.
llvm-svn: 93214
(C++ [temp.mem]p5-6), which involves template argument deduction based
on the type named, e.g., given
struct X { template<typename T> operator T*(); } x;
when we call
x.operator int*();
we perform template argument deduction to determine that T=int. This
template argument deduction is needed for template specialization and
explicit instantiation, e.g.,
template<> X::operator float*() { /* ... */ }
and when calling or otherwise naming a conversion function (as in the
first example).
This fixes PR5742 and PR5762, although there's some remaining ugliness
that's causing out-of-line definitions of conversion function
templates to fail. I'll look into that separately.
llvm-svn: 93162
not just the viable ones. This is reasonable because the most common use of
deleted functions is to exclude some implicit conversion during calls; users
therefore will want to figure out why some other options were excluded.
Started sorting overload results. Right now it just sorts by location in the
translation unit (after putting viable functions first), but we can do better than
that.
Changed bool OnlyViable parameter to PrintOverloadCandidates to an enum for better
self-documentation.
llvm-svn: 92990
no viable overloads. Use a different message when the class provides
no operator[] overloads at all; use it for operator(), too.
Partially addresses PR 5900.
llvm-svn: 92894
typo.cpp:22:10: error: use of undeclared identifier 'radious'; did
you mean 'radius'?
return radious * pi;
^~~~~~~
radius
This was super-easy, since we already had decent recovery by looking
for names in dependent base classes.
llvm-svn: 92341
more or less cv-qualified than another during implicit conversion and overload
resolution ([basic.type.qualifier] p5). Factors the logic out of template
deduction and into the ASTContext so it can be shared.
This fixes several aspects of PR5542, but not all of them.
llvm-svn: 92248
address resolution. This fixes PR5751.
Also, while we're here, remove logic from ADL which mistakenly included the
definition namespaces of overloaded and/or templated functions whose name or
address is used as an argument.
llvm-svn: 92245
constructor call, the conversion is only a standard conversion
sequence if that constructor is a copy constructor. This fixes PR5834
in a semi-lame way, because the "real" fix will be to move over to
InitializationSequence. That will happen "soonish", but not now.
llvm-svn: 91861
explicitly-specified template arguments are enough to determine the
instantiation, and either template argument deduction fails or is not
performed in that context, we can resolve the template-id down to a
function template specialization (so sayeth C++0x
[temp.arg.explicit]p3). Fixes PR5811.
llvm-svn: 91852
function in a C++ call using an arbitrary call-expression type.
Actually exploit this to fix the recovery implemented earlier.
The diagnostic is still iffy, though.
llvm-svn: 91538
used as expressions). In dependent contexts, try to recover by doing a lookup
in previously-dependent base classes. We get better diagnostics out, but
unfortunately the recovery fails: we need to turn it into a method call
expression, not a bare call expression. Thus this is still a WIP.
llvm-svn: 91525
are a couple of O(n^2) operations in this, some analogous to the usual O(n^2)
redeclaration problem and some not. In particular, retroactively removing
shadow declarations when they're hidden by later decls is pretty unfortunate.
I'm not yet convinced it's worse than the alternative, though.
llvm-svn: 91045
new notion of an "initialization sequence", which encapsulates the
computation of the initialization sequence along with diagnostic
information and the capability to turn the computed sequence into an
expression. At present, I've only switched one CheckReferenceInit
callers over to this new mechanism; more will follow.
Aside from (hopefully) being much more true to the standard, the
diagnostics provided by this reference-initialization code are a bit
better than before. Some examples:
p5-var.cpp:54:12: error: non-const lvalue reference to type 'struct
Derived'
cannot bind to a value of unrelated type 'struct Base'
Derived &dr2 = b; // expected-error{{non-const lvalue reference to
...
^ ~
p5-var.cpp:55:9: error: binding of reference to type 'struct Base' to
a value of
type 'struct Base const' drops qualifiers
Base &br3 = bc; // expected-error{{drops qualifiers}}
^ ~~
p5-var.cpp:57:15: error: ambiguous conversion from derived class
'struct Diamond' to base class 'struct Base':
struct Diamond -> struct Derived -> struct Base
struct Diamond -> struct Derived2 -> struct Base
Base &br5 = diamond; // expected-error{{ambiguous conversion from
...
^~~~~~~
p5-var.cpp:59:9: error: non-const lvalue reference to type 'long'
cannot bind to
a value of unrelated type 'int'
long &lr = i; // expected-error{{non-const lvalue reference to type
...
^ ~
p5-var.cpp:74:9: error: non-const lvalue reference to type 'struct
Base' cannot
bind to a temporary of type 'struct Base'
Base &br1 = Base(); // expected-error{{non-const lvalue reference to
...
^ ~~~~~~
p5-var.cpp:102:9: error: non-const reference cannot bind to bit-field
'i'
int & ir1 = (ib.i); // expected-error{{non-const reference cannot
...
^ ~~~~~~
p5-var.cpp:98:7: note: bit-field is declared here
int i : 17; // expected-note{{bit-field is declared here}}
^
llvm-svn: 90992
"integer promotion" type associated with an enum decl, and use this type to
determine which type to promote to. This type obeys C++ [conv.prom]p2 and
is therefore generally signed unless the range of the enumerators forces
it to be unsigned.
Kills off a lot of false positives from -Wsign-compare in C++, addressing
rdar://7455616
llvm-svn: 90965
using value decls; we optimistically assume they won't turn into conflicts.
Teach it to tell the caller *why* the function doesn't overload with the returned
decl; this will be useful for using hiding.
llvm-svn: 90939
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
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
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
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
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
- 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
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
(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
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
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
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
to all callers. Switch a few other users of CK_Unknown to proper cast
kinds.
Note that there are still some situations where we end up with
CK_Unknown; they're pretty easy to find with grep. There
are still a few missing conversion kinds, specifically
pointer/int/float->bool and the various combinations of real/complex
float/int->real/complex float/int.
llvm-svn: 84623
The most important effect of this is that function templates only referenced by address expressions now get instantiated. This, in turn, means that Hello World compiles with the Apache stdcxx library even when using endl.
llvm-svn: 84363
Taking the address of an overloaded function with an explicit address-of operator wrapped the operator in an implicit cast that added yet another pointer level, leaving us with a corrupted AST, which crashed CodeGen in the test case I've added. Fix this by making FixOverloadedFunctionReference return whether there was an address-of operator and not adding the implicit cast in that case.
llvm-svn: 84362
sets of builtin operators. Currently, it is applied
to '++' and '->*' operators. I need to apply it to others
as well. Also, heuristics need be applied to
BuiltinCandidateTypeSet::AddPointerWithMoreQualifiedTypeVariants.
This is WIP.
llvm-svn: 84187
to a member operator template. We missed updating this call site when
adding support for function templates; bug exposed by a test for
PR5072.
llvm-svn: 84111
user-defined type conversions, issue list of ambiguites in addition
to the diagnostic. So, clang now issues the following:
b.cpp:19:19: error: left hand operand to ->* must be a pointer to class compatible with the right hand operand, but is 'struct C1'
int i = c1->*pmf;
~~^
b.cpp:19:19: note: because of ambiguity in conversion of 'struct C1' to 'struct E *'
b.cpp:5:5: note: candidate function
operator E*();
^
b.cpp:11:5: note: candidate function
operator E*();
^
llvm-svn: 83862
struct B;
B f();
void g() {
f();
}
We now get
t.cpp:6:3: error: calling 'f' with incomplete return type 'struct B'
f();
^~~
t.cpp:3:3: note: 'f' declared here
B f();
^
t.cpp:1:8: note: forward declaration of 'struct B'
struct B;
^
llvm-svn: 83692
Now we produce things like:
bug1.cpp:21:11: error: use of overloaded operator '->*' is ambiguous
int i = c->*pmf; // expected-error {{use of overloaded operator '->*' is ambiguous}} \
~^ ~~~
bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A volatile *', 'int const struct A::*')
bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A volatile *', 'int restrict struct A::*')
...
Still need to look at an issue (indicated as FIXME in the test case).
llvm-svn: 83650
Doug, please review. There is a FIXME in the test case with a question
which is unrelated to this patch (that is, error is issued
before set of builtins are added to the candidate list).
llvm-svn: 83429
for bases, members, overridden virtual methods, etc. The operations
isDerivedFrom and lookupInBases are now provided by CXXRecordDecl,
rather than by Sema, so that CodeGen and other clients can use them
directly.
llvm-svn: 83396
overload candidates (but not the built-in ones). We still rely on the
underlying built-in semantic analysis to produce the initial
diagnostic, then print the candidates following that diagnostic.
One side advantage of this approach is that we can perform more validation
of C++'s operator overloading with built-in candidates vs. the
semantic analysis for those built-in operators: when there are no
viable candidates, we know to expect an error from the built-in
operator handling code. Otherwise, we are not modeling the built-in
semantics properly within operator overloading. This is checked as:
assert(Result.isInvalid() &&
"C++ binary operator overloading is missing
candidates!");
if (Result.isInvalid())
PrintOverloadCandidates(CandidateSet, /*OnlyViable=*/false);
The assert() catches cases where we're wrong in a +Asserts build. The
"if" makes sure that, if this happens in a production clang
(-Asserts), we still build the proper built-in operator and continue
on our merry way. This is effectively what happened before this
change, but we've added the assert() to catch more flies.
llvm-svn: 83175
had to do with an initialized field when multiple type conversions
are ambiguous but must be treated as user defined conversion for
overload resolution purposes.
llvm-svn: 83079
value-dependent. Audit (and fixed) all calls to
Expr::isNullPointerConstant() to provide the correct behavior with
value-dependent expressions. Fixes PR5041 and a crash in libstdc++
<locale>.
In the same vein, properly compute value- and type-dependence for
ChooseExpr. Fixes PR4996.
llvm-svn: 82748
first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks
There are many caveats here:
- We completely and totally drop any explicitly-specified template
arguments on the floor
- We don't diagnose any of the extra semantic things that we should
diagnose.
- I haven't looked to see that we're getting the right linkage for
explicit specializations
On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.
llvm-svn: 82728
Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right; many more remain.
llvm-svn: 82705
that there is one more argument (the one following the comma) and make
the candidate non-viable if the function cannot accept any argument in
that position.
llvm-svn: 82625
opening parentheses and after each comma. We gather the set of visible
overloaded functions, perform "partial" overloading based on the set
of arguments that we have thus far, and return the still-viable
results sorted by the likelihood that they will be the best candidate.
Most of the changes in this patch are a refactoring of the overloading
routines for a function call, since we needed to separate out the
notion of building an overload set (common to code-completion and
normal semantic analysis) and then what to do with that overload
set. As part of this change, I've pushed explicit template arguments
into a few more subroutines.
There is still much more work to do in this area. Function templates
won't be handled well (unless we happen to deduce all of the template
arguments before we hit the completion point), nor will overloaded
function-call operators or calls to member functions.
llvm-svn: 82549
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
point at the template and print out its template arguments, e.g.,
ambiguous-ovl-print.cpp:5:8: note: candidate function template specialization
[with T = int]
void f(T*, long);
llvm-svn: 81907
that type. Note that we do not produce a diagnostic if the type is
incomplete; rather, we just don't look for conversion functions. Fixes PR4660.
llvm-svn: 79919
and will participate in overload resolution. Unify the instantiation
of CXXMethodDecls and CXXConstructorDecls, which had already gotten
out-of-sync.
llvm-svn: 79658
- Allowing one to name a member function template within a class
template and on the right-hand side of a member access expression.
- Template argument deduction for calls to member function templates.
- Registering specializations of member function templates (and
finding them later).
llvm-svn: 79581
where sizeof(short) == sizeof(int). Move UsualArithmeticConversionsType
out of Sema, since it was only there as a historical artifact. Patch by
Enea Zaffanella.
llvm-svn: 79412
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
llvm-svn: 77510
- Move Sema::ObjCQualifiedIdTypesAreCompatible(), Sema::QualifiedIdConformsQualifiedId(), and a couple helper functions to ASTContext.
- Change ASTContext::canAssignObjCInterfaces() to use ASTContext:: ObjCQualifiedIdTypesAreCompatible().
- Tweak several test cases to accommodate the new/improved type checking.
llvm-svn: 76830
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
llvm-svn: 76193
This method is intended to eventually replace the individual
Type::getAsXXXType<> methods.
The motivation behind this change is twofold:
1) Reduce redundant implementations of Type::getAsXXXType() methods. Most of
them are basically copy-and-paste.
2) By centralizing the implementation of the getAs<Type> logic we can more
smoothly move over to Doug Gregor's proposed canonical type smart pointer
scheme.
Along with this patch:
a) Removed 'Type::getAsPointerType()'; now clients use getAs<PointerType>.
b) Removed 'Type::getAsBlockPointerTypE()'; now clients use getAs<BlockPointerType>.
llvm-svn: 76098
This removes the static data/methods on ObjCObjectPointerType while preserving the nice API (no need to fiddle with ASTContext:-).
This patch also adds Type::isObjCBuiltinType().
This should be the last fairly large patch related to recrafting the ObjC type system. The follow-on patches should be fairly small.
llvm-svn: 75808
The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches.
This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic.
By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time.
Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks.
llvm-svn: 75314
function template. Most of the change here is in factoring out the
common bits used for template argument deduction from a function call
and when taking the address of a function template.
llvm-svn: 75044
substitute those template arguments into the function parameter types
prior to template argument deduction. There's still a bit of work to
do to make this work properly when only some of the template arguments
are specified.
llvm-svn: 74576
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
llvm-svn: 74506
The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.
This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.
llvm-svn: 74501
templates.
For example, this now type-checks (but does not instantiate the body
of deref<int>):
template<typename T> T& deref(T* t) { return *t; }
void test(int *ip) {
int &ir = deref(ip);
}
Specific changes/additions:
* Template argument deduction from a call to a function template.
* Instantiation of a function template specializations (just the
declarations) from the template arguments deduced from a call.
* FunctionTemplateDecls are stored directly in declaration contexts
and found via name lookup (all forms), rather than finding the
FunctionDecl and then realizing it is a template. This is
responsible for most of the churn, since some of the core
declaration matching and lookup code assumes that all functions are
FunctionDecls.
llvm-svn: 74213
C++. This logic is required to trigger implicit instantiation of
function templates and member functions of class templates, which will
be implemented separately.
This commit includes support for -Wunused-parameter, printing warnings
for named parameters that are not used within a function/Objective-C
method/block. Fixes <rdar://problem/6505209>.
llvm-svn: 73797
into the left-hand side of an assignment expression. This completes
most of PR3500; the only remaining part is to deal with the
GCC-specific implementation-defined behavior for "unsigned long" (and
other) bit-fields.
llvm-svn: 70623
Douglas Gregor