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
Douglas Gregor