| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 94485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
quality of their
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
|
| |
|
|
| |
llvm-svn: 94136
|
| |
|
|
| |
llvm-svn: 94053
|
| |
|
|
|
|
|
| |
pointer to an any object. Another variation of
radar 7562285.
llvm-svn: 94052
|
| |
|
|
|
|
|
| |
So, casting a generic object pointer ('id' or 'Class') to the
block pointer is allowed. Fixes radar 7562285.
llvm-svn: 94045
|
| |
|
|
|
|
|
| |
Change LookupResult to use UnresolvedSet. Also extract UnresolvedSet into its
own header and make it templated over an inline capacity.
llvm-svn: 93959
|
| |
|
|
|
|
| |
a similar pointer. Fixes radar 7552179.
llvm-svn: 93803
|
| |
|
|
| |
llvm-svn: 93629
|
| |
|
|
|
|
|
|
| |
stand at the back of the line.
Thanks to Oliver Hunt for reminding me to do this.
llvm-svn: 93583
|
| |
|
|
|
|
|
| |
for special diagnostics. Unfortunately, the non-overload diagnostics are not
this good.
llvm-svn: 93420
|
| |
|
|
|
|
| |
about 'object argument' vs. 'nth argument'.
llvm-svn: 93395
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|