| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
new expression.
This was voted into C++20 as a defect report resolution, so we
retroactively apply it to all prior language modes (though it can never
actually be used before C++11 mode).
llvm-svn: 360006
|
|
|
|
|
|
| |
This is C++14 with conforming GNU extensions.
llvm-svn: 320250
|
|
|
|
|
|
|
|
| |
[Test] Make Lit tests C++11 compatible #9
Differential Revision: https://reviews.llvm.org/D20710
llvm-svn: 296184
|
|
|
|
| |
llvm-svn: 269572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls
ActOnStartCXXMemberReference() to inform sema that a member reference is about
to start, and that function lets the parser know if sema thinks that the
base expression's type could allow a pseudo destructor from a semantic point of
view (for example, if the the base expression has a dependent type).
ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and
passes MayBePseudoDestructor on to that function, expecting the function to
set it to false if a pseudo destructor is impossible from a syntactic point of
view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier()
had early-outs for ::new and __super, so MayBePseudoDestructor stayed true,
so we tried to parse a pseudo dtor, and then became confused since we couldn't
find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets
MayBePseudoDestructor to false above the early exits.
Parts of this found by SLi's bot.
llvm-svn: 229449
|
|
|
|
|
|
| |
PR19968!
llvm-svn: 210388
|
|
|
|
|
|
| |
such an assert will fail in invalid code that does so!
llvm-svn: 199617
|
|
|
|
|
|
|
|
| |
pointer, since this invokes undefined behavior. Based on a patch by Artyom
Skrobov! Handling of dependent exception specifications and some additional
testcases by me.
llvm-svn: 199452
|
|
|
|
|
|
|
| |
it's also __attribute__((used)), since that undoes the problematic part of
'inline'.
llvm-svn: 194916
|
|
|
|
|
|
|
| |
projects are relying on such (questionable) practices, so we should give them
a way to opt out of this diagnostic.
llvm-svn: 194905
|
|
|
|
| |
llvm-svn: 193061
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR17591.
N.B. This actually goes beyond what the standard mandates by requiring
the restriction to hold for declarations instead of definitions. This
is believed to be a defect in the standard and an LWG issue has been
submitted.
llvm-svn: 193044
|
|
|
|
|
|
| |
not actually talking about a default constructor.
llvm-svn: 183885
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
common function. The C++1y contextual implicit conversion rules themselves are
not yet implemented, however.
This also fixes a subtle bug where template instantiation context notes were
dropped for diagnostics coming from conversions for integral constant
expressions -- we were implicitly slicing a SemaDiagnosticBuilder into a
DiagnosticBuilder when producing these diagnostics, and losing their context
notes in the process.
llvm-svn: 182406
|
|
|
|
|
|
| |
<rdar://problem/12857416>.
llvm-svn: 170056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject
array sizes and array indexes which begin with a lambda-expression. Recover by
parsing the lambda as a lambda.
* In Objective-C++11, either '[' could be the start of a message-send.
Fully disambiguate this case: it turns out that the grammars of message-sends,
lambdas and attributes do not actually overlap. Accept any occurrence of '[['
where either '[' starts a message send, but reject a lambda in an array index
just like in C++11 mode.
Implement a couple of changes to the attribute wording which occurred after our
attributes implementation landed:
* In a function-declaration, the attributes go after the exception specification,
not after the right paren.
* A reference type can have attributes applied.
* An 'identifier' in an attribute can also be a keyword. Support for alternative
tokens (iso646 keywords) in attributes to follow.
And some bug fixes:
* Parse attributes after declarator-ids, even if they are not simple identifiers.
* Do not accept attributes after a parenthesized declarator.
* Accept attributes after an array size in a new-type-id.
* Partially disamiguate 'delete' followed by a lambda. More work is required
here for the case where the lambda-introducer is '[]'.
llvm-svn: 154369
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defined here, but not semantically, so
new struct S {};
is always ill-formed, even if there is a struct S in scope.
We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.
llvm-svn: 152549
|
|
|
|
|
|
| |
I think there's a deeper problem here in the way TransformCXXConstructExpr works, but I won't tackle it now.
llvm-svn: 151146
|
|
|
|
|
|
| |
Don't know what I was thinking there. Fixes PR12023.
llvm-svn: 150804
|
|
|
|
|
|
|
|
| |
hold the used constructor itself.""
This reintroduces commit r150682 with a fix for the Bullet benchmark crash.
llvm-svn: 150685
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
|
|
|
|
|
|
|
| |
array new expression. This lays some groundwork for the implicit conversion to
integral or unscoped enumeration which C++11 ICEs undergo.
llvm-svn: 149772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new, is well-formed with defined semantics of throwing (a type which can be
caught by a handler for) std::bad_array_new_length, unlike in C++98 where it is
somewhere nebulous between undefined behavior and ill-formed.
If the array size is an integral constant expression and satisfies one of these
criteria, we would previous the array new expression, but now in C++11 mode, we
merely issue a warning (the code is still rejected in C++98 mode, naturally).
We don't yet implement new C++11 semantics correctly (see PR11644), but we do
implement the overflow checking, and (for the default operator new) convert such
expressions to an exception, so accepting such code now does not seem especially
unsafe.
llvm-svn: 149767
|
|
|
|
|
|
| |
their undefined behavior.
llvm-svn: 136183
|
|
|
|
|
|
|
|
| |
destructor. PR10504.
I'm not completely sure the standard allows us to reject this, but if it doesn't, it should. :)
llvm-svn: 136172
|
|
|
|
|
|
|
|
|
| |
1. Attempting to delete an expression of incomplete class type should be an error, not a warning.
2. If someone tries to delete a pointer to an incomplete class type, make sure we actually emit
the delete expression after we warn.
llvm-svn: 136161
|
|
|
|
|
|
|
| |
it as used. Otherwise, we can fail to instantiate or validate the destructor,
which can lead to crashes in IR gen like PR10351.
llvm-svn: 135073
|
|
|
|
|
|
| |
from Alex Miller!
llvm-svn: 124663
|
|
|
|
|
|
| |
PR7702.
llvm-svn: 118181
|
|
|
|
|
|
|
| |
placement 'operator delete', even if there are no placement args (i.e.
overload resolution selected an operator new with default arguments).
llvm-svn: 113861
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
first parameter of operator delete
llvm-svn: 112298
|
|
|
|
| |
llvm-svn: 110542
|
|
|
|
| |
llvm-svn: 110294
|
|
|
|
|
|
| |
before looking for conversions to pointer type. Fixes <rdar://problem/8248780>.
llvm-svn: 109749
|
|
|
|
|
|
|
|
|
|
|
|
| |
size" error for code like
new (int [size])
to a warning, add a Fix-It to remove the parentheses, and make this
diagnostic work properly when it occurs in a template
instantiation. <rdar://problem/8018245>.
llvm-svn: 108242
|
|
|
|
|
|
|
|
|
|
|
| |
type to an integral or enumeration type in the size of an array new
expression, e.g.,
new int[ConvertibleToInt(10)];
This is a GNU and C++0x extension.
llvm-svn: 107229
|
|
|
|
|
|
|
|
|
| |
much as we already do for allocation function lookup. Explicitly check access
for the function we actually select in one case that was previously missing,
but being caught behind the blanket diagnostics for all overload candidates.
This fixs PR7436.
llvm-svn: 106986
|
|
|
|
|
|
|
| |
extension warning (which other compilers seem to use). Works around a
known bug in Xalan.
llvm-svn: 104509
|
|
|
|
|
|
| |
type is a typedef to an array type.
llvm-svn: 103909
|
|
|
|
|
|
|
| |
of an array type, use the outermost array bound as the number of
elements to allocate. Fixes PR7147.
llvm-svn: 103908
|
|
|
|
| |
llvm-svn: 102917
|
|
|
|
|
|
|
|
| |
Remove -faccess-control from -cc1; add -fno-access-control.
Make the driver pass -fno-access-control by default.
Update a bunch of tests to be correct under access control.
llvm-svn: 100880
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
disaster. Fixes PR6161.
llvm-svn: 96371
|
|
|
|
| |
llvm-svn: 95553
|
|
|
|
|
|
|
|
|
|
|
| |
prevent a crash on templates when looking for an existing declaration of the
predefined global operators. This fixes PR5918.
Added an easy test case for the overload handling, but testing the crash is
a bit trickier. Created a new test that can use multiple runs with a define to
trigger which test case is used so we can test this type of issue.
llvm-svn: 95220
|
|
|
|
|
|
| |
copy constructors) come first. Also, fix a bug where EK_New was left out of the err_init_conversion_failed diagnostic (It is now reported as 'new value'). Please review Doug :)
llvm-svn: 94289
|
|
|
|
|
|
|
|
| |
size_t. Also, fix an issue with initialization of parameters in calls,
where we weren't removing the cv-qualifiers on the parameter type
itself. Fixes PR5823.
llvm-svn: 91941
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
than using its own partial implementation of initialization.
Switched CheckInitializerTypes over to
InitializedEntity/InitializationKind, to help move us closer to
InitializationSequence.
Added InitializedEntity::getName() to retrieve the name of the entity,
for diagnostics that care about such things.
Implemented support for default initialization in
InitializationSequence.
Clean up the determination of the "source expressions" for an
initialization sequence in InitializationSequence::Perform.
Taught CXXConstructExpr to store more location information.
llvm-svn: 91492
|