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
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
- 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
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
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
- 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
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
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
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
explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.
llvm-svn: 151001
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
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
instead of having a special-purpose function.
- ActOnCXXDirectInitializer, which was mostly duplication of
AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
int x = {1};
int x({1});
int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
always produces a ParenListExpr. Placed that so far failed to convert that
back to a ParenExpr containing comma operators have been fixed. I'm pretty
sure I could have made a crashing test case before this.
The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)
This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.
llvm-svn: 150318
empty union. This still rejects anonymous member structs or unions which only
contain such empty class types, pending standard wording defining exactly what
an empty class type is.
llvm-svn: 150157
the sign bit doesn't have undefined behavior, but a signed left shift of a 1 bit
out of the sign bit still does. As promised to Howard :)
The suppression of the potential constant expression checking in system headers
is also removed, since the problem it was working around is gone.
llvm-svn: 150059
can't produce a constant expression is not ill-formed (so long as some
instantiation of that function can produce a constant expression).
llvm-svn: 149802
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
The recent support for potential constant expressions exposed a bug in the
implementation of libstdc++4.6, where numeric_limits<int>::min() is defined
as (int)1 << 31, which isn't a constant expression. Disable the 'constexpr
function never produces a constant expression' error inside system headers
to compensate.
llvm-svn: 149729
function definition can produce a constant expression. This also provides the
last few checks for [dcl.constexpr]p3 and [dcl.constexpr]p4.
llvm-svn: 149108
pointer to incomplete type from an ExtWarn to an error. We put the
ExtWarn in place as part of a workaround for Boost (PR6527), but it
(1) doesn't actually match a GCC extension and (2) has been fixed for
two years in Boost, and (3) causes us to emit code that fails badly at
run time, so it's a bad idea to keep it. Fixes PR11803.
llvm-svn: 148838
This is the last piece of N3031 (decltype in weird places) - supporting
the use of decltype in a class ctor's member-initializer-list to
specify the base classes to initialize.
Reviewed by Richard Smith.
llvm-svn: 148789
Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.
llvm-svn: 148735
MSVC2010's pair class has a move assignment operator but no explicit copy
constructor, which makes it unusable without this change.
For symmetry, let move copy constructors not mark the default assignment
operator as deleted either. Both changes match cl.exe's behavior. Fixes
pr11826.
Also update the standard excerpt to point to the right paragraph.
llvm-svn: 148675
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).
Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.
llvm-svn: 148187
are still added if the cached correction fails validation.
Also fix a copy-and-paste error in a comment from my previous commit.
Finally, add an example of the benefit the typo correction callback adds
to TryNamespaceTypoCorrection--which happens to also tickle the above
caching problem, as the only way a non-namespace Decl would be added to
the possible corrections is if it was cached as the correction for a
previous instance of the same typo where the typo was corrected to a
non-namespace via a different code path.
llvm-svn: 147968
Also includes two examples of the callback: a wrapper/replacement for
the CorrectTypoContext enum, and a conversion of the two calls to
CorrectTypo in SemaDeclCXX.cpp (one of which provides verifiable
improvement to the typo correction, as demonstrated in the added test).
llvm-svn: 147962
- reject definitions of enums within friend declarations
- require 'enum', not 'enum class', for non-declaring references to scoped
enumerations
llvm-svn: 147824
to Redeclarable<NamespaceDecl>, so that we benefit from the improveed
redeclaration deserialization and merging logic provided by
Redeclarable<T>. Otherwise, no functionality change.
As a drive-by fix, collapse the "inline" bit into the low bit of the
original namespace/anonymous namespace, saving 8 bytes per
NamespaceDecl on x86_64.
llvm-svn: 147729
Split out a new ExpressionEvaluationContext flag for this case, and don't treat
it as unevaluated in C++11. This fixes some crash-on-invalids where we would
allow references to class members in potentially-evaluated constant expressions
in static member functions, and also fixes half of PR10177.
The fix to PR10177 exposed a case where template instantiation failed to provide
a source location for a diagnostic, so TreeTransform has been tweaked to supply
source locations when transforming a type. The source location is still not very
good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to
improve it further.
Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for
static data members of class templates which are used in constant expressions.
This fixes a link-time problem, but we still incorrectly treat the member as
non-constant. The rest of the fix for that issue is blocked on PCH support for
early-instantiated static data members, which will be added in a subsequent
patch.
llvm-svn: 146955
when computing the exception specification of a copy or move constructor,
ignore non-static data member initializers. Fixes PR11418 /
<rdar://problem/10478642>.
llvm-svn: 145269
initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.
llvm-svn: 144028
definition, we may not have a scope corresponding to the namespace
where that friend function template actually lives. Work around this
issue by faking up a scope with the appropriate DeclContext.
This is a bit of a hack, but it fixes <rdar://problem/10204947>.
llvm-svn: 143614
wrong class, make sure to drop it immediately; we don't want that
constructor to be available within the DeclContext. Fixes
<rdar://problem/9677163>.
llvm-svn: 143506
that it retains source location information for the type. Aside from
general goodness (being able to walk the types described in that
information), we now have a proper representation for dependent
delegating constructors. Fixes PR10457 (for real).
llvm-svn: 143410
Nick Lewycky