| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The [class.protected] restriction is non-trivial for any instance
member, even if the access lacks an object (for example, if it's
a pointer-to-member constant). In this case, it is equivalent to
requiring the naming class to equal the context class.
- The [class.protected] restriction applies to accesses to constructors
and destructors. A protected constructor or destructor can only be
used to create or destroy a base subobject, as a direct result.
- Several places were dropping or misapplying object information.
The standard could really be much clearer about what the object type is
supposed to be in some of these accesses. Usually it's easy enough to
find a reasonable answer, but still, the standard makes a very confident
statement about accesses to instance members only being possible in
either pointer-to-member literals or member access expressions, which
just completely ignores concepts like constructor and destructor
calls, using declarations, unevaluated field references, etc.
llvm-svn: 154248
|
| |
|
|
|
|
| |
a namespace alias declaration.
llvm-svn: 154138
|
| |
|
|
| |
llvm-svn: 153985
|
| |
|
|
|
|
| |
'copy assignment operator'.
llvm-svn: 153897
|
| |
|
|
|
|
| |
explicitly, deleted in all relevant cases, and explain why.
llvm-svn: 153894
|
| |
|
|
|
|
|
|
|
|
|
| |
move constructor/move assignment operator are not declared, rather than being
defined as deleted, so move operations on the derived class fall back to
copying rather than moving.
If a move operation on the derived class is explicitly defaulted, the
unmovable subobject will be copied instead of being moved.
llvm-svn: 153883
|
| |
|
|
|
|
| |
dependent contexts.
llvm-svn: 153858
|
| |
|
|
|
|
| |
member function is deleted.
llvm-svn: 153773
|
| |
|
|
| |
llvm-svn: 153673
|
| |
|
|
|
|
|
|
|
| |
concerning qualified declarator-ids. We now diagnose extraneous
qualification at namespace scope (which we had previously missed) and
diagnose these qualification errors for all kinds of declarations; it
was rather uneven before. Fixes <rdar://problem/11135644>.
llvm-svn: 153577
|
| |
|
|
|
|
| |
This fixes g++.dg/parse/friend5.C.
llvm-svn: 152938
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
void f () {
int g (int a, int b=4);
{
int g(int a, int b=5);
}
}
should compile.
llvm-svn: 152621
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
llvm-svn: 152608
|
| |
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
| |
|
|
|
|
| |
does not imply that such functions can't be declared at block scope.
llvm-svn: 152509
|
| |
|
|
|
|
|
|
| |
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
llvm-svn: 152491
|
| |
|
|
|
|
| |
doing a copy. Fixes PR12139.
llvm-svn: 152485
|
| |
|
|
|
|
|
|
|
| |
- getSourceRange().getBegin() is about as awesome a pattern as .copy().size().
I already killed the hot paths so this doesn't seem to impact performance on my
tests-of-the-day, but it is a much more sensible (and shorter) pattern.
llvm-svn: 152419
|
| |
|
|
| |
llvm-svn: 152394
|
| |
|
|
|
|
| |
and lots of tidying up.
llvm-svn: 152392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
starting with an underscore is ill-formed.
Since this rule rejects programs that were using <inttypes.h>'s macros, recover
from this error by treating the ud-suffix as a separate preprocessing-token,
with a DefaultError ExtWarn. The approach of treating such cases as two tokens
is under discussion for standardization, but is in any case a conforming
extension and allows existing codebases to keep building while the committee
makes up its mind.
Reword the warning on the definition of literal operators not starting with
underscores (which are, strangely, legal) to more explicitly state that such
operators can't be called by literals. Remove the special-case diagnostic for
hexfloats, since it was both triggering in the wrong cases and incorrect.
llvm-svn: 152287
|
| |
|
|
|
|
|
| |
string literal, and adjust the diagnostic code to match. This also causes us
to escape any control characters in the message.
llvm-svn: 152069
|
| |
|
|
| |
llvm-svn: 152033
|
| |
|
|
| |
llvm-svn: 151997
|
| |
|
|
|
|
|
|
| |
generated block literal for lambdas which are immediately converted to block pointer type. This simplifies the AST, avoids an unnecessary copy of the lambda and makes it much easier to avoid copying the result onto the heap.
Note that this transformation has a substantial semantic effect outside of ARC: it gives the converted lambda lifetime semantics similar to a block literal. With ARC, the effect is much less obvious because the lifetime of blocks is already managed.
llvm-svn: 151797
|
| |
|
|
|
|
|
| |
default constructor of a union if it has a const member with no user-provided
default constructor.
llvm-svn: 151516
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- variant members with nontrivial destructors make the containing class's
destructor deleted
- check for a virtual destructor after checking for overridden methods in the
base class(es)
- check for an inaccessible operator delete for a class with a virtual
destructor.
Do not try to call an anonymous union field's destructor from the destructor of
the containing class.
llvm-svn: 151483
|
| |
|
|
| |
llvm-svn: 151478
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
trivial if the implicit declaration would be. Don't forget to set the Trivial
flag on the special member as well as on the class. It doesn't seem ideal that
we have two separate mechanisms for storing this information, but this patch
does not attempt to address that.
This leaves us in an interesting position where the has_trivial_X trait for a
class says 'yes' for a deleted but trivial X, but is_trivially_Xable says 'no'.
This seems to be what the standard requires.
llvm-svn: 151465
|
| |
|
|
|
|
| |
implement the retain+autorelease outside of ARC, and there's a bug that causes the generated code to crash in ARC (which I think is unrelated to my code, although I'm not completely sure).
llvm-svn: 151428
|
| |
|
|
|
|
|
|
|
|
|
| |
explicit conversion functions to initialize the argument to a
copy/move constructor that itself is the subject of direct
initialization. Since we don't have that much context in overload
resolution, we end up threading more flags :(.
Fixes <rdar://problem/10903741> / PR10456.
llvm-svn: 151409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A defaulted default constructor for a class X is defined as deleted if [...]
- X is a union and all of its variant members are of const-qualified type.
A pedantic reading therefore says that
union X { };
has a deleted default constructor, which is both silly and almost
certainly unintended. Pretend as if this this read
- X is a union with one or more variant members, and all of its
variant members are of const-qualified type.
llvm-svn: 151394
|
| |
|
|
|
|
| |
optimization, the current implementation is also a denser.
llvm-svn: 151257
|
| |
|
|
|
|
| |
direct member initializers.
llvm-svn: 151155
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are left
unspecified, namely the capture variable (which doesn't actually
exist) and the body (which will be filled in by IRgen because it can't
be written as an AST).
Because we're switching to this model, this patch also eliminates
tracking the copy-initialization expression for the block capture of
the conversion function, since that information is now embedded in the
synthesized block literal. -1 side tables FTW.
llvm-svn: 151131
|
| |
|
|
|
|
| |
initializers of data members (both static and non-static).
llvm-svn: 151017
|
| |
|
|
|
|
|
| |
explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.
llvm-svn: 151001
|
| |
|
|
| |
llvm-svn: 150933
|
| |
|
|
|
|
|
|
| |
<rdar://problem/10885993>.
This should probably be refactored... but it isn't completely obvious what refactoring is best.
llvm-svn: 150869
|
| |
|
|
|
|
|
|
|
|
| |
We had two separate issues here: firstly, varions functions were assuming that
they did not need to perform semantic checks on trivial destructors (this is
not true in C++11, where a trivial destructor can nonetheless be private or
deleted), and a bunch of DiagnoseUseOfDecl calls were missing for uses of
destructors.
llvm-svn: 150866
|
| |
|
|
|
|
|
|
|
| |
decent diagnostics. Finish the work of combining all the 'ShouldDelete'
functions into one. In unifying the code, fix a minor bug where an anonymous
union with a deleted default constructor as a member of a union wasn't being
considered as making the outer union's default constructor deleted.
llvm-svn: 150862
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conversion to function pointer. Rather than having IRgen synthesize
the body of this function, we instead introduce a static member
function "__invoke" with the same signature as the lambda's
operator() in the AST. Sema then generates a body for the conversion
to function pointer which simply returns the address of __invoke. This
approach makes it easier to evaluate a call to the conversion function
as a constant, makes the linkage of the __invoke function follow the
normal rules for member functions, and may make life easier down the
road if we ever want to constexpr'ify some of lambdas.
Note that IR generation is responsible for filling in the body of
__invoke (Sema just adds a dummy body), because the body can't
generally be expressed in C++.
Eli, please review!
llvm-svn: 150783
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pointers and block pointers). We use dummy definitions to keep the
invariant that an implicit, used definition has a body; IR generation
will substitute the actual contents, since they can't be represented
as C++.
For the block pointer case, compute the copy-initialization needed to
capture the lambda object in the block, which IR generation will need
later.
llvm-svn: 150645
|
| |
|
|
|
|
|
|
|
| |
function, provide a specialized diagnostic that indicates the kind of
special member function (default constructor, copy assignment
operator, etc.) and that it was implicitly deleted. Add a hook where
we can provide more detailed information later.
llvm-svn: 150611
|
| |
|
|
|
|
|
|
| |
lambda expressions. Because these issue was pulled back from Ready
status at the Kona meeting, we still emit an ExtWarn when using
default arguments for lambda expressions.
llvm-svn: 150519
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* if, switch, range-based for: warn if semicolon is on the same line.
* for, while: warn if semicolon is on the same line and either next
statement is compound statement or next statement has more
indentation.
Replacing the semicolon with {} or moving the semicolon to the next
line will always silence the warning.
Tests from SemaCXX/if-empty-body.cpp merged into SemaCXX/warn-empty-body.cpp.
llvm-svn: 150515
|
| |
|
|
| |
llvm-svn: 150475
|
| |
|
|
|
|
|
|
|
|
| |
the instantiation of a constexpr function temploid is now always constexpr, a
defaulted constexpr function temploid is often ill-formed by the rule in
[dcl.fct.def.default]p2 that an explicitly-defaulted constexpr function must
have a constexpr implicit definition. To avoid making loads of completely
reasonable code ill-formed, do not apply that rule to templates.
llvm-svn: 150453
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1358, 1360, 1452 and 1453.
- Instantiations of constexpr functions are always constexpr. This removes the
need for separate declaration/definition checking, which is now gone.
- This makes it possible for a constexpr function to be virtual, if they are
only dependently virtual. Virtual calls to such functions are not constant
expressions.
- Likewise, it's now possible for a literal type to have virtual base classes.
A constexpr constructor for such a type cannot actually produce a constant
expression, though, so add a special-case diagnostic for a constructor call
to such a type rather than trying to evaluate it.
- Classes with trivial default constructors (for which value initialization can
produce a fully-initialized value) are considered literal types.
- Classes with volatile members are not literal types.
- constexpr constructors can be members of non-literal types. We do not yet use
static initialization for global objects constructed in this way.
llvm-svn: 150359
|
| |
|
|
|
|
| |
assignment operator, per C++ [expr.prim.lambda]p19. Make it so.
llvm-svn: 150345
|