| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicit functions that are not candidates.
It's not always obvious that the reason a conversion was not possible is
because the function you wanted to call is 'explicit', so explicitly say
if that's the case.
It would be nice to rank the explicit candidates higher in the
diagnostic if an implicit conversion sequence exists for their
arguments, but unfortunately we can't determine that without potentially
triggering non-immediate-context errors that we're not permitted to
produce.
|
|
|
|
|
|
|
|
|
| |
Improved wording and also simplified by using printing
method from qualifiers.
Differential Revision: https://reviews.llvm.org/D62914
llvm-svn: 364023
|
|
|
|
|
|
| |
only invoke converting constructors of the reference's underlying type.
llvm-svn: 336153
|
|
|
|
|
|
|
|
| |
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.
llvm-svn: 321310
|
|
|
|
|
|
| |
Misc/ast-dump-color.cpp.
llvm-svn: 321229
|
|
|
|
|
|
| |
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
llvm-svn: 321223
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mirror the description in the standard. Per DR1295, this means that binding a
const / rvalue reference to a bit-field no longer "binds directly", and per
P0135R1, this means that we materialize a temporary in reference binding
after adjusting cv-qualifiers and before performing a derived-to-base cast.
In C++11 onwards, this should have fixed the last case where we would
materialize a temporary of the wrong type (with a subobject adjustment inside
the MaterializeTemporaryExpr instead of outside), but we still have to deal
with that possibility in C++98, unless we want to start using xvalues to
represent materialized temporaries there too.
llvm-svn: 289250
|
|
|
|
| |
llvm-svn: 284906
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copy-initialization. We previously got this wrong in a couple of ways:
- we only looked for copy / move constructors and constructor templates for
this copy, and thus would fail to copy in cases where doing so should use
some other constructor (but see core issue 670),
- we mishandled the special case for disabling user-defined conversions that
blocks infinite recursion through repeated application of a copy constructor
(applying it in slightly too many cases) -- though as far as I can tell,
this does not ever actually affect the result of overload resolution, and
- we misapplied the special-case rules for constructors taking a parameter
whose type is a (reference to) the same class type by incorrectly assuming
that only happens for copy/move constructors (it also happens for
constructors instantiated from templates and those inherited from base
classes).
These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.
llvm-svn: 280776
|
|
|
|
|
|
| |
C++ language standard is not C++98.
llvm-svn: 280309
|
|
|
|
|
|
|
| |
Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 253371
|
|
|
|
| |
llvm-svn: 237507
|
|
|
|
| |
llvm-svn: 237505
|
|
|
|
|
|
|
|
| |
The error has the form ... 'int' ... 'const int' ... dropped qualifiers. At
first glance, it appears that the const qualifier is added. Reverse the types
so that the second type is less qualified than the first.
llvm-svn: 237482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reasoning is that this construct is accepted by all compilers and valid in
C++11, so it doesn't seem like a useful warning to have enabled by default.
Building with -pedantic, -Wbind-to-temporary-copy, or -Wc++98-compat still
shows the warning.
The motivation is that I built re2, and this was the only warning that was
emitted during the build. Both changing re2 to fix the warning and detecting
clang and suppressing the warning in re2's build seem inferior than just giving
the compiler a good default for this warning.
Also move the cxx98compat version of this warning to CXX98CompatPedantic, and
update tests accordingly.
llvm-svn: 218008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
llvm-svn: 181252
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For this source:
const int &ref = someStruct.bitfield;
We used to generate this AST:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'const int' lvalue <NoOp>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Notice the lvalue inside the MaterializeTemporaryExpr, which is very
confusing (and caused an assertion to fire in the analyzer - PR15694).
We now generate this:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'int' <LValueToRValue>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Which makes a lot more sense. This allows us to remove code in both
CodeGen and AST that hacked around this special case.
The commit also makes Clang accept this (legal) C++11 code:
int &&ref = std::move(someStruct).bitfield
PR15694 / <rdar://problem/13600396>
llvm-svn: 179250
|
|
|
|
|
|
| |
reference to an lvalue of compatible type.
llvm-svn: 178095
|
|
|
|
|
|
|
|
| |
http://llvm-reviews.chandlerc.com/D52
Patch by Philip Craig!
llvm-svn: 170634
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
because it expects a reference and receives a non-l-value.
For example, given:
int foo(int &);
template<int x> void b() { foo(x); }
clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment #5 in PR3104, and should be the last bit of work needed for the
bug.
llvm-svn: 158691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Ahmed Charles!
llvm-svn: 142340
|
|
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
|
|
|
|
|
|
|
|
| |
conversion function whose result type is an lvalue reference. The
initialization code already handled this properly, but overload
resolution was allowing the binding. Fixes PR11003 /
<rdar://problem/10233078>.
llvm-svn: 141137
|
|
|
|
|
|
|
| |
conversion to initialize the standard conversion *after* the
user-defined conversion properly. Fixes PR10644.
llvm-svn: 137608
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
which seem to be working fine
llvm-svn: 123955
|
|
|
|
|
|
|
|
|
|
| |
specification. In particular, an rvalue reference can bind to an
initializer expression that is an lvalue if the referent type and the
initializer expression type are not reference-related. This is a newer
formulation to the previous "rvalue references can never bind to
lvalues" rule.
llvm-svn: 123952
|
|
|
|
|
|
|
| |
type checking based on the actual reference type we're trying to bind
the result to, rather than stripping the reference.
llvm-svn: 123950
|
|
|
|
|
|
|
| |
references. Note that we're currently failing reference binding to a
function lvalue.
llvm-svn: 123920
|
|
|
|
|
|
|
| |
working paper's structure. The only functional change here is that we
now handling binding to array rvalues, which we would previously reject.
llvm-svn: 123918
|
|
|
|
|
|
|
|
|
| |
involving rvalue references, to start scoping out what is and what
isn't implemented. In the process, tweak some standards citations,
type desugaring, and teach the tentative parser about && in
ptr-operator.
llvm-svn: 123913
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
|
|
|
|
|
|
|
| |
direct-initialization (rather than copy-initialization) to initialize
the temporary, allowing explicit constructors. Fixes PR8342.
llvm-svn: 118880
|
|
|
|
|
|
|
|
|
| |
the overload candidates.
Fixes an infinite recursion in overload resolution for rdar://8499524.
Many thanks to Doug!
llvm-svn: 115588
|
|
|
|
| |
llvm-svn: 113092
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
constructor into an extension warning into the error that C++98 requires.
llvm-svn: 105529
|
|
|
|
| |
llvm-svn: 105351
|
|
|
|
| |
llvm-svn: 102259
|
|
|
|
|
|
|
|
|
| |
reference binding to an rvalue of reference-compatible type, check
parameters after the first for complete parameter types and build any
required default function arguments. We're effectively simulating the
type-checking for a call without building the call itself.
llvm-svn: 101705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference-compatible type, the implementation is permitted to make a
copy of the rvalue (or many such copies, even). However, even though
we don't make that copy, we are required to check for the presence of
a suitable copy constructor. With this change, we do.
Note that in C++0x we are not allowed to make these copies, so we test
both dialects separately.
Also note the FIXME in one of the C++03 tests, where we are not
instantiating default function arguments for the copy constructor we
pick (but do not call). The fix is obvious; eliminating the infinite
recursion it causes is not. Will address that next.
llvm-svn: 101704
|
|
|
|
|
|
|
| |
direct reference binding when the source and target types are not
reference-related. Fixes PR6066.
llvm-svn: 101132
|
|
|
|
|
|
|
|
|
|
| |
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
llvm-svn: 98149
|
|
|
|
| |
llvm-svn: 97202
|
|
|
|
|
|
| |
to bitfields. Add it here.
llvm-svn: 94832
|
|
|
|
|
|
|
| |
previously, we were allowing this to bind to a temporary. Now, we
don't; add test-cases and improve diagnostics.
llvm-svn: 94831
|