| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
should be resolvable, from Faisal Vali!
llvm-svn: 127521
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
MemberExpr, the last of the expressions with qualifiers!
llvm-svn: 126688
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
where ever such attribute causes an error diagnostic.
llvm-svn: 126509
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
// rdar://9046492
llvm-svn: 126499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
nested-name-specifier and source range to be set at the same time.
llvm-svn: 126347
|
|
|
|
| |
llvm-svn: 126084
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 125468
|
|
|
|
|
|
|
| |
implementation of co/contra-variance objc++
block pointers. // rdar://8979379.
llvm-svn: 125467
|
|
|
|
|
|
|
| |
types which are contravariance in argument types and covariance
in return types. // rdar://8979379.
llvm-svn: 125445
|
|
|
|
| |
llvm-svn: 125217
|
|
|
|
|
|
| |
and probably only works for very basic use cases.
llvm-svn: 124970
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 124364
|
|
|
|
| |
llvm-svn: 124363
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
for the implicit object argument to a non-static member function with
a ref-qualifier (C++0x [over.match.funcs]p4).
llvm-svn: 124311
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
rules), now that we've actually have a clean build for me to sully.
llvm-svn: 124290
|
|
|
|
| |
llvm-svn: 124247
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 124033
|
|
|
|
|
|
|
| |
reference to an rvalue rather than binding a const-qualified lvalue
reference to that rvalue.
llvm-svn: 123979
|
|
|
|
| |
llvm-svn: 123978
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
declaration that name lookup actually found, so that we can use it for
access checking later on. Fixes <rdar://problem/8876150>.
llvm-svn: 123867
|
|
|
|
|
|
|
| |
so allow it to propagate the failure outward. Fixes the crashing part
of <rdar://problem/8876150>.
llvm-svn: 123863
|
|
|
|
|
|
|
| |
overload resolution, so that we only use that number of call arguments
for partial ordering. Fixes PR9006, a recent regression.
llvm-svn: 123861
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
thousand other things which were (generally inadvertantly) relying on that.
llvm-svn: 123814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
resolution require that the pointed-to type be an object type, but we
weren't filtering out non-object types. Do so, fixing PR7851.
llvm-svn: 122853
|
|
|
|
|
|
|
|
|
| |
conversions, make sure that the (possibly) derived type is complete
before looking for base classes.
Finishes the fix for PR8801.
llvm-svn: 122363
|
|
|
|
|
|
|
| |
Apply the noreturn attribute while creating a builtin function's type.
Remove the getNoReturnType() API.
llvm-svn: 122295
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
candidates. They're now wrapped in nice APIs which hide the tables, etc. Also
removes some repetitive code from clients.
llvm-svn: 121634
|