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
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
type-specifier in C++. Some checks will assert in this case otherwise (in
particular, the access specifier may be missing if this happens inside a class
definition, due to a violation of an AST invariant).
llvm-svn: 198721
conversion function when we're binding the result to a reference, drop
cv-qualifiers on the type we're referring to, since we should be
deducing a type that can be adjusted (via cv-qualification) to the
requested type. Fixes PR9336, and the remaining Boost.Assign failure.
llvm-svn: 127117
sequences for two conversion functions when in fact we are in the text
of initialization by a user-defined conversion sequences. Fixes PR8034.
llvm-svn: 113724
conversion a second time for a conversion candidate (with the real
acting context), because the only problems we would find are access or
ambiguity issues that won't be diagnosed until we pick this
candidate. Add a test case to prove it to myself.
llvm-svn: 111526
conversion functions as if their acting context were the class that
we're converting from (the implicit object argument's
type). Retroactively tweaking the implicit conversion sequence, as we
were trying to do before, breaks the invariants of that implicit
conversion sequence (e.g., the types and conversions don't match
up). Fixes <rdar://problem/8018274>.
llvm-svn: 111520
implicit conversion sequences. In particular, model the "standard
conversion" from a class to its own type (or a base type) directly as
a standard conversion in the normal path *without* trying to determine
if there is a valid copy constructor. This appears to match the intent
of C++ [over.best.ics]p6 and more closely matches GCC and EDG.
As part of this, model non-lvalue reference initialization via
user-defined conversion in overloading the same way we handle it in
InitializationSequence, separating the "general user-defined
conversion" and "conversion to compatible class type" cases.
The churn in the overload-call-copycon.cpp test case is because the
test case was originally wrong; it assumed that we should do more
checking for copy constructors that we actually should, which affected
overload resolution.
Fixes PR7055. Bootstrapped okay.
llvm-svn: 110773
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
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
copying the type location information from the conversion-type-id into
the type location information for the function type. Do something
similar for constructors and destructors, by giving their "void"
return type source-location information.
In all of these cases, we previously left this type-source information
uninitialized, which led to various unfortunate crashes.
We still aren't tracking good source-location information for the
actual names. That's PR6357.
John, please check my sanity on this.
llvm-svn: 101088
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
InitializationSequence. Specially, switch initialization of a C++
class type (either copy- or direct-initialization).
Also, make sure that we create an elidable copy-construction when
performing copy initialization of a C++ class variable. Fixes PR5826.
llvm-svn: 91750
new InitializationSequence. This fixes some bugs (e.g., PR5808),
changed some diagnostics, and caused more churn than expected. What's
new:
- InitializationSequence now has a "C conversion sequence" category
and step kind, which falls back to
- Changed the diagnostics for returns to always have the result type
of the function first and the type of the expression second.
CheckSingleAssignmentConstraints to peform checking in C.
- Improved ASTs for initialization of return values. The ASTs now
capture all of the temporaries we need to create, but
intentionally do not bind the tempoary that is actually returned,
so that it won't get destroyed twice.
- Make sure to perform an (elidable!) copy of the class object that
is returned from a class.
- Fix copy elision in CodeGen to properly see through the
subexpressions that occur with elidable copies.
- Give "new" its own entity kind; as with return values and thrown
objects, we don't bind the expression so we don't call a
destructor for it.
Note that, with this patch, I've broken returning move-only types in
C++0x. We'll fix it later, when we tackle NRVO.
llvm-svn: 91669
used as expressions). In dependent contexts, try to recover by doing a lookup
in previously-dependent base classes. We get better diagnostics out, but
unfortunately the recovery fails: we need to turn it into a method call
expression, not a bare call expression. Thus this is still a WIP.
llvm-svn: 91525
- 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
a class type from itself or a derived class thereof, enumerate
constructors and permit user-defined conversions to the arguments of
those constructors. This fixes the wacky implicit conversion sequence
used in std::auto_ptr's lame emulation of move semantics.
llvm-svn: 88670
Remove an atrocious amount of trailing whitespace in the overloaded operator mangler. Sorry, couldn't help myself.
Change the DeclType parameter of Sema::CheckReferenceInit to be passed by value instead of reference. It wasn't changed anywhere.
Let the parser handle C++'s irregular grammar around assignment-expression and conditional-expression.
And finally, the reason for all this stuff: implement C++ semantics for the conditional operator. The implementation is complete except for determining lvalueness.
llvm-svn: 69299
unqualified-id '('
in C++. The unqualified-id might not refer to any declaration in our
current scope, but declarations by that name might be found via
argument-dependent lookup. We now do so properly.
As part of this change, CXXDependentNameExpr, which was previously
designed to express the unqualified-id in the above constructor within
templates, has become UnresolvedFunctionNameExpr, which does
effectively the same thing but will work for both templates and
non-templates.
Additionally, we cope with all unqualified-ids, since ADL also applies
in cases like
operator+(x, y)
llvm-svn: 63733
DeclRefExprs and BlockDeclRefExprs into a single function
Sema::ActOnDeclarationNameExpr, eliminating a bunch of duplicate
lookup-name-and-check-the-result code.
Note that we still have the three parser entry points for identifiers,
operator-function-ids, and conversion-function-ids, since the parser
doesn't (and shouldn't) know about DeclarationNames. This is a Good
Thing (TM), and there will be more entrypoints coming (e.g., for C++
pseudo-destructor expressions).
llvm-svn: 59527
destructors, and conversion functions. The placeholders were used to
work around the fact that the parser and some of Sema really wanted
declarators to have simple identifiers; now, the code that deals with
declarators will use DeclarationNames.
llvm-svn: 59469
C++ constructors, destructors, and conversion functions now have a
FETokenInfo field that IdentifierResolver can access, so that these
special names are handled just like ordinary identifiers. A few other
Sema routines now use DeclarationNames instead of IdentifierInfo*'s.
To validate this design, this code also implements parsing and
semantic analysis for id-expressions that name conversion functions,
e.g.,
return operator bool();
The new parser action ActOnConversionFunctionExpr takes the result of
parsing "operator type-id" and turning it into an expression, using
the IdentifierResolver with the DeclarationName of the conversion
function. ActOnDeclarator pushes those conversion function names into
scope so that the IdentifierResolver can find them, of course.
llvm-svn: 59462
functions in C++, e.g.,
struct X {
operator bool() const;
};
Note that these conversions don't actually do anything, since we don't
yet have the ability to use them for implicit or explicit conversions.
llvm-svn: 58860
David Majnemer