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
David Blaikie