| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per review discussion in r170365
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the cases where we can't determine whether special members would be trivial
while building the class, we eagerly declare those special members. The impact
of this is bounded, since it does not trigger implicit declarations of special
members in classes which merely *use* those classes.
In order to determine whether we need to apply this rule, we also need to
eagerly declare move operations and destructors in cases where they might be
deleted. If a move operation were supposed to be deleted, it would instead
be suppressed, and we could need overload resolution to determine if we fall
back to a trivial copy operation. If a destructor were implicitly deleted,
it would cause the move constructor of any derived classes to be suppressed.
As discussed on cxx-abi-dev, C++11's selected constructor rules are also
retroactively applied as a defect resolution in C++03 mode, in order to
identify that class B has a non-trivial copy constructor (since it calls
A's constructor template, not A's copy constructor):
struct A { template<typename T> A(T &); };
struct B { mutable A a; };
llvm-svn: 169673
|
|
|
|
|
|
|
|
| |
properly, rather than faking it up by pretending that a reference member makes
the default constructor non-trivial. That leads to rejects-valids when putting
such types inside unions.
llvm-svn: 169662
|
|
|
|
|
|
| |
that was skipped by the parser.
llvm-svn: 169531
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 168977
|
|
|
|
|
|
|
| |
constructor/assignment operator with a const-qualified parameter type. The
prior method for determining this incorrectly used overload resolution.
llvm-svn: 168775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference instead of relying on computing it.
In general, if storage is no issue, it is preferable to deserialize info from
the PCH instead of trying to recompute it after the PCH was loaded.
The incentive to change this now was due to r155303 changing how friend template
classes in dependent contexts are handled; such classes can now be chained to
a previous template class but the computed InjectedClassNameType may be different
due to the extra template parameters from the dependent context.
The new handling requires more investigation but, in the meantime, writing out
InjectedClassNameType fixes PCH issue in rdar://12627738.
llvm-svn: 167425
|
|
|
|
|
|
|
|
|
| |
has ivars that require destruction, but none that require anything
except zero-initialization. This is common in ARC and (when true
throughout a class hierarchy) permits the elimination of an
unnecessary message-send during allocation.
llvm-svn: 166088
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).
This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.
llvm-svn: 165626
|
|
|
|
|
|
|
|
|
|
| |
whether that function/method already has a body (loaded from some
other AST file), as introduced in r165137. Delay this check until
after the redeclaration chains have been wired up.
While I'm here, make the loading of method bodies lazy.
llvm-svn: 165513
|
|
|
|
|
|
| |
decision about whether we need to call tryAddTopLevelDecl or not. That call should be made when the DeclContext's redeclaration context is the translation unit.
llvm-svn: 165215
|
|
|
|
|
|
|
| |
which is neither correct nor necessary. The use of this routine was
eliminated by r165137.
llvm-svn: 165139
|
|
|
|
| |
llvm-svn: 165138
|
|
|
|
|
|
|
| |
the ASTReader doesn't attach a body to a function that is already
defined elsewhere.
llvm-svn: 165137
|
|
|
|
|
|
|
|
| |
ImportDecl's module ID was not written out and the reader accepted as module ID
the serialized:
Record.push_back(!IdentifierLocs.empty());
llvm-svn: 165087
|
|
|
|
|
|
|
|
| |
the merging should have set it correctly.
This is especially relevant for templatedDecls that might be injected (and thus have their DeclContext set to) somewhere completely different.
llvm-svn: 165005
|
|
|
|
|
|
| |
the ASTConsumer.
llvm-svn: 165001
|
|
|
|
|
|
|
|
|
|
|
| |
Check whether a pending instantiation needs to be instantiated (or whether an instantiation already exists).
Verify the size of the PendingInstantiations record (was only checking size of existing PendingInstantiations).
Migrate Obj-C++ part of redecl-merge into separate test, now that this is growing.
templates.mm: test that CodeGen has seen exactly one definition of template instantiations.
redecl-merge.m: use "@" specifier for expected-diagnostics.
llvm-svn: 164993
|
|
|
|
|
|
| |
Don't require specializations (of existing and read template) to be unique.
llvm-svn: 164931
|
|
|
|
|
|
|
|
|
| |
specialization was written, which is non-canonical at the time of reading: force the reading of the ClassTemplateDecl if it was written.
The easiest way out is to store whether the decl was canonical at the time of writing.
Add test.
llvm-svn: 164927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
but not
external visible decls, call DeclContext::setMustBuildLookupTable so that the
"lazy decls" bit of the LookupPtr is set.
Previously, in non-C++, if there were no new declarations causing the "lazy decls" bit
to be set, then DeclContext::lookups_begin() would fail to return the decls from the PCH.
Fixes rdar://12316296.
llvm-svn: 164351
|
|
|
|
| |
llvm-svn: 164335
|
|
|
|
|
|
|
|
| |
definition info; it needs to be there because the mangler needs to
access it before we're finished defining the lambda class.
PR12808.
llvm-svn: 164186
|
|
|
|
|
|
| |
changes.
llvm-svn: 164106
|
|
|
|
| |
llvm-svn: 163983
|
|
|
|
|
|
| |
Unfortunately, no test case. rdar://11960120
llvm-svn: 163566
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.
Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).
llvm-svn: 163369
|
|
|
|
| |
llvm-svn: 163032
|
|
|
|
|
|
| |
instead of aliasing to "struct" which had some incorrect behaviour. Patch by David Robins.
llvm-svn: 163013
|
|
|
|
| |
llvm-svn: 162361
|
|
|
|
|
|
|
|
| |
previous ResetObjCLayout calls since this is now handled in Sema.
Part of rdar://11842763
llvm-svn: 160527
|
|
|
|
|
|
|
| |
static_assert fails when parsing the template, don't diagnose it again on every
instantiation.
llvm-svn: 160088
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
method definition that has its '{' attached to the method name without
a space.
With a method like:
-(id)meth{
.....
}
the logic in ObjCMethodDecl that determined the selector locations got
confused because it was initialized based on an end location for '{' but
that end location changed to '}' after the method was finished.
Fix this by having an immutable end location for the declarator and
for getLocEnd() get the end location from the body itself.
Fixes rdar://11659739.
llvm-svn: 158583
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need an efficient mechanism to determine whether a defaulted default
constructor is constexpr, in order to determine whether a class is a literal
type, so keep the incrementally-built form on CXXRecordDecl. Remove the
on-demand computation of same, so that we only have one method for determining
whether a default constructor is constexpr. This doesn't affect correctness,
since default constructor lookup is much simpler than selecting a constructor
for copying or moving.
We don't need a corresponding mechanism for defaulted copy or move constructors,
since they can't affect whether a type is a literal type. Conversely, checking
whether such functions are constexpr can require non-trivial effort, so we defer
such checks until the copy or move constructor is required.
Thus we now only compute whether a copy or move constructor is constexpr on
demand, and only compute whether a default constructor is constexpr in advance.
This is unfortunate, but seems like the best solution.
llvm-svn: 158290
|
|
|
|
|
|
|
| |
initialization, and use that information to produce the right kind of
initialization during template instantiation.
llvm-svn: 158288
|
|
|
|
|
|
|
|
| |
derive from it.
Use actual factory functions rather than derived classes acting as named constructors/factories.
llvm-svn: 157588
|
|
|
|
| |
llvm-svn: 156923
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reserving a bit
in ObjCMethodDecl to indicate whether the method does not override any other method,
which is the majority of cases.
That way we can avoid unnecessary work doing lookups, especially when PCH is involved.
rdar://11360082
llvm-svn: 156476
|
|
|
|
|
|
|
|
|
| |
in-class initializer for one of its fields. Value-initialization of such
a type should use the in-class initializer!
The former was just a bug, the latter is a (reported) standard defect.
llvm-svn: 156274
|
|
|
|
|
|
| |
Part of rdar://11353109.
llvm-svn: 156185
|
|
|
|
|
|
| |
rdar://11353109
llvm-svn: 156145
|
|
|
|
|
|
| |
Fixes rdar://11353109 & http://llvm.org/bugs/show_bug.cgi?id=12689
llvm-svn: 156056
|
|
|
|
|
|
|
|
| |
delete.
It would be nice to use OwningPtr here, but DeclContextInfo is stored in a DenseMap.
llvm-svn: 154763
|
|
|
|
| |
llvm-svn: 154676
|
|
|
|
|
|
|
|
| |
scoped enumeration members. Later uses of an enumeration temploid as a nested
name specifier should cause its instantiation. Plus some groundwork for
explicit specialization of member enumerations of class templates.
llvm-svn: 152750
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
| |
have matching user defined setter/getter and a warning is issued.
In this case, a fixit note is displayed. // rdar://10267155
llvm-svn: 151766
|
|
|
|
|
|
|
|
|
| |
data members for deleted or user-provided destructors.
Now it's computed in advance, serialize it, and in passing fix all the other
record DefinitionData flags whose serialization was missing.
llvm-svn: 151441
|