| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
that we aren't using ForceRValue any more?
llvm-svn: 101496
|
|
|
|
| |
llvm-svn: 101494
|
|
|
|
|
|
| |
functions.
llvm-svn: 101492
|
|
|
|
|
|
| |
not the way we're going to handle this.
llvm-svn: 101483
|
|
|
|
|
|
| |
Sema::IsUserDefinedConversion. No functionality change
llvm-svn: 101482
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
correction find names when a call failed. Fixes
<rdar://problem/7853795>.
llvm-svn: 101278
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
return a NULL expression; return either an error or a proper
expression. Fixes PR6078.
llvm-svn: 101133
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 100732
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 99979
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
re-route its only caller to the newer
PerformCopyInitialization(). We're down to one remaining caller of
Sema::CheckReferenceInit.
llvm-svn: 99650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
required when emitting a destructor definition.
llvm-svn: 98609
|
|
|
|
|
|
| |
considering valid objc pointer converions.
llvm-svn: 98557
|
|
|
|
| |
llvm-svn: 97686
|
|
|
|
| |
llvm-svn: 97677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 97404
|
|
|
|
|
|
|
| |
binding and a copy-construction. Fixes an overloading problem in the
Clang-on-Clang build.
llvm-svn: 97161
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
When diagnosing bad conversions, skip the conversion for ignored object
arguments. Fixes PR 6398.
llvm-svn: 97090
|
|
|
|
|
|
| |
between cv1 T* and cv2 T*.
llvm-svn: 96787
|
|
|
|
|
|
| |
type (per C++ [class.copy]p3). Make sure that includes copies that involve a derived-to-base conversion. Fixes PR6141.
llvm-svn: 96742
|
|
|
|
|
|
|
| |
conversions. Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path. Prepare for friends.
llvm-svn: 95775
|
|
|
|
|
|
|
| |
may be some other places that could take advantage of this new information,
but I haven't really looked yet.
llvm-svn: 95600
|
|
|
|
|
|
|
| |
post-increment/post-decrement operators, be sure to consider both
arguments. Fixes PR6237.
llvm-svn: 95361
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 95239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
UnresolvedMemberExpr and employ it in a few places where it's useful.
llvm-svn: 95072
|
|
|
|
|
|
| |
as an argument during overload resolution.
llvm-svn: 95057
|
|
|
|
|
|
|
| |
deduction failed. Right now there's a very vague diagnostic for most cases
and a good diagnostic for incomplete deduction.
llvm-svn: 94988
|
|
|
|
| |
llvm-svn: 94824
|
|
|
|
| |
llvm-svn: 94823
|
|
|
|
|
|
| |
to get the access bits set properly in conversion sets.
llvm-svn: 94744
|
|
|
|
|
|
|
|
| |
mostly because we're going to want a better diagnostic for conversions.
Also this API needs to go back to sanity.
llvm-svn: 94730
|
|
|
|
| |
llvm-svn: 94725
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
diagnostics in "early" lookups, such as during typename checks and when building
unresolved lookup expressions.
llvm-svn: 94647
|
|
|
|
| |
llvm-svn: 94531
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
about interaction between ADL and default arguments. Shrug shoulders, commit.
llvm-svn: 94524
|
|
|
|
|
|
| |
general refactoring in operator resolution.
llvm-svn: 94498
|