| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.
This re-commits r290808, reverted in r290811 and r291412, with a couple of
fixes for handling of explicitly-specified non-trailing template argument
packs.
llvm-svn: 291427
|
| |
|
|
|
|
| |
The test-suite bots are still failing even after r291410's fix.
llvm-svn: 291412
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.
This re-commits r290808, reverted in r290811, with a fix for handling of
explicitly-specified template argument packs.
llvm-svn: 291410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation."
This reverts commit r290808, as it broken all ARM and AArch64 test-suite
test: MultiSource/UnitTests/C++11/frame_layout
Also, please, next time, try to write a commit message in according to
our guidelines:
http://llvm.org/docs/DeveloperPolicy.html#commit-messages
llvm-svn: 290811
|
| |
|
|
|
|
|
|
|
|
|
|
| |
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside
the immediate context is much more common during substitution than during
implicit conversion sequence formation.
This does not implement the partial ordering portion of DR1391, which so
far appears to be misguided.
llvm-svn: 290808
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r280553 introduced an issue where we'd emit ambiguity errors for code
like:
```
void foo(int *, int);
void foo(unsigned int *, unsigned int);
void callFoo() {
unsigned int i;
foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int,
// but unsigned int*->unsigned int* is better than
// int*->int*.
}
```
This patch fixes this issue by changing how we handle ill-formed (but
valid) implicit conversions. Candidates with said conversions now always
rank worse than candidates without them, and two candidates are
considered to be equally bad if they both have these conversions for
the same argument.
Additionally, this fixes a case in C++11 where we'd complain about an
ambiguity in a case like:
```
void f(char *, int);
void f(const char *, unsigned);
void g() { f("abc", 0); }
```
...Since conversion to char* from a string literal is considered
ill-formed in C++11 (and deprecated in C++03), but we accept it as an
extension.
llvm-svn: 280847
|
| |
|
|
|
|
|
|
|
|
| |
candidate with a parameter of incomplete (ref or pointer) type
Reviewers: dblaikie
Differential Revision: http://reviews.llvm.org/D16949
llvm-svn: 262752
|
| |
|
|
|
|
|
|
| |
This is the 5th Lit test patch.
Expanded expected diagnostics to vary by C++ dialect.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 255196
|
| |
|
|
|
|
|
| |
Our self hosting buildbots found a few more tests which weren't updated
to reflect that the enum semantics are part of the Microsoft ABI.
llvm-svn: 249670
|
| |
|
|
|
|
|
|
| |
array prvalue), treat that as a direct binding. Only the class prvalue case
needs to be excluded here; the rest are extensions anyway, so we can treat them
as we would in C++11.
llvm-svn: 212978
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
a function pointer is neither better nor worse than binding a function lvalue
to a function rvalue reference. Don't get confused and think that both bindings
are binding to a function lvalue (which would make the lvalue form win); the
const reference is binding to an rvalue.
The "real" bug in PR20218 is still present: we're getting the wrong answer from
template argument deduction, and that's what leads us to this weird overload
set.
llvm-svn: 212916
|
| |
|
|
| |
llvm-svn: 208138
|
| |
|
|
|
|
|
|
| |
volatile reference to a temporary is not viable. My interpretation is that
DR1152 was a bugfix, not a rule change for C++11, so this is not conditional on
the language mode. This matches g++'s behavior.
llvm-svn: 157370
|
| |
|
|
|
|
|
|
|
|
|
| |
Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.
Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.
llvm-svn: 156826
|
| |
|
|
|
|
| |
the sole parameter name in the diagnostic in more cases. Patch by Terry Long!
llvm-svn: 156807
|
| |
|
|
|
|
|
| |
which expects exactly one argument, include the name of the argument in
the diagnostic text. Patch by Terry Long!
llvm-svn: 156607
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.
The test changes are a bit of a mixed bag. Some tests that seemed like they
clearly didn't need to use this behavior have been modified not to use it.
Others that I couldn't be sure about, I added the necessary expected-warnings
to.
It's possible the diagnostic message could be improved to make it clearer that
this warning can be suppressed by using a value that won't lose precision when
converted to the target type (but can still be a floating point literal, such
as "bool b = 1.0;").
llvm-svn: 154068
|
| |
|
|
|
|
| |
innermost type. Fixes PR12142.
llvm-svn: 152456
|
| |
|
|
|
|
|
|
| |
associated classes, since it can find friend functions declared within them,
but overload resolution does not otherwise require argument types to be
complete.
llvm-svn: 151434
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function call (or a comma expression with a function call on its right-hand
side), possibly parenthesized, then the return type is not required to be
complete and a temporary is not bound. Other subexpressions inside a decltype
expression do not get this treatment.
This is implemented by deferring the relevant checks for all calls immediately
within a decltype expression, then, when the expression is fully-parsed,
checking the relevant constraints and stripping off any top-level temporary
binding.
Deferring the completion of the return type exposed a bug in overload
resolution where completion of the argument types was not attempted, which
is also fixed by this change.
llvm-svn: 151117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
|
| |
|
|
|
|
| |
functions, e.g., (&f)(0). Fixes <rdar://problem/9803316>.
llvm-svn: 141877
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
That bug concerned the well-formedness of code such as (&ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&ovl) is neither.
llvm-svn: 118620
|
| |
|
|
|
|
| |
with, e.g., (&f)(a, b, c). Fixes PR8013.
llvm-svn: 118508
|
| |
|
|
| |
llvm-svn: 115590
|
| |
|
|
|
|
|
| |
which is should have done from the beginning. As usual, the most
fun with this sort of change is updating all the testcases.
llvm-svn: 113090
|
| |
|
|
|
|
| |
pointer" diagnostic to handle references, too.
llvm-svn: 107372
|
| |
|
|
|
|
| |
require a base-to-derived pointer conversion.
llvm-svn: 107349
|
| |
|
|
|
|
| |
literals. Fixes PR7488.
llvm-svn: 106607
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
being a subsequence of another standard conversion sequence. Instead
of requiring exact type equality for the second conversion step,
require type *similarity*, which is type equality with cv-qualifiers
removed at all levels. This appears to match the behavior of EDG and
VC++ (albeit not GCC), and feels more intuitive. Big thanks to John
for the line of reasoning that supports this change: since
cv-qualifiers are orthogonal to the second conversion step, we should
ignore them in the type comparison.
llvm-svn: 105678
|
| |
|
|
|
|
| |
derived-to-base conversion on a pointer. Fixes PR7224.
llvm-svn: 104607
|
| |
|
|
|
|
| |
conversion. Fixes PR7095.
llvm-svn: 104476
|
| |
|
|
|
|
|
|
|
|
|
| |
copy constructor, suppress user-defined conversions on the
argument. Otherwise, we can end up in a recursion loop where the
bind the argument of the copy constructor to another copy constructor call,
whose argument is then a copy constructor call...
Found by Boost.Regex which, alas, still isn't building.
llvm-svn: 102269
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:
t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
type 'int *' [-pedantic]
f(long_ptr);
^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
^
llvm-svn: 102038
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
return a NULL expression; return either an error or a proper
expression. Fixes PR6078.
llvm-svn: 101133
|
| |
|
|
|
|
|
| |
that is not reference-related (because it requires another implicit
conversion to which we can find). Fixes PR6483.
llvm-svn: 97922
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
| |
When diagnosing bad conversions, skip the conversion for ignored object
arguments. Fixes PR 6398.
llvm-svn: 97090
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
fidelity with which we note them as functions/constructors and templates
thereof. Also will be helpful when reporting bad conversions (next).
llvm-svn: 93224
|
| |
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|