| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
over ivars for a varienty of puposes is now
consolidated into two small routines; DeepCollectObjCIvars
and ShallowCollectObjCIvars.
llvm-svn: 111679
|
|
|
|
|
|
|
|
|
|
| |
active C++ ABI as a raw string, we store it as an enum. This should improve
performance somewhat.
And yes, this time, I started from a clean build directory, and
all the tests passed. :)
llvm-svn: 111507
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now all classes derived from Attr are generated from TableGen.
Additionally, Attr* is no longer its own linked list; SmallVectors or
Attr* are used. The accompanying LLVM commit contains the updates to
TableGen necessary for this.
Some other notes about newly-generated attribute classes:
- The constructor arguments are a SourceLocation and a Context&,
followed by the attributes arguments in the order that they were
defined in Attr.td
- Every argument in Attr.td has an appropriate accessor named getFoo,
and there are sometimes a few extra ones (such as to get the length
of a variadic argument).
Additionally, specific_attr_iterator has been introduced, which will
iterate over an AttrVec, but only over attributes of a certain type. It
can be accessed through either Decl::specific_attr_begin/end or
the global functions of the same name.
llvm-svn: 111455
|
|
|
|
| |
llvm-svn: 111314
|
|
|
|
|
|
|
|
| |
AST library.
This also adds infrastructure for supporting multiple C++ ABIs in the AST.
llvm-svn: 111117
|
|
|
|
| |
llvm-svn: 111091
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unused warnings for functions:
-static functions
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace
Unused warnings for variables:
-static variables
-variables in anonymous namespace
-static data members in anonymous namespace
-static data members specializations in anonymous namespace
Reveals lots of opportunities for dead code removal in llvm codebase that will
interest my esteemed colleagues.
llvm-svn: 111086
|
|
|
|
| |
llvm-svn: 110950
|
|
|
|
| |
llvm-svn: 110860
|
|
|
|
|
|
|
|
| |
and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
breakage.
llvm-svn: 110803
|
|
|
|
|
|
|
|
|
|
| |
forward declarations and the definition.
- Eagerly create ObjCInterfaceTypes for declarations.
- The two above changes lead to a 0.5% increase in memory use and no speed regression when parsing Cocoa.h. On the other hand, now chained PCH works when there's a forward declaration in one PCH and the interface definition in another.
- Add HandleInterestingDecl to ASTConsumer. PCHReader passes the "interesting" decls it finds to this function instead of HandleTopLevelDecl. The default implementation forwards to HandleTopLevelDecl, but ASTUnit's handler for example ignores them. This fixes a potential crash when lazy loading of PCH data would cause ASTUnit's "top level" declaration collection to change while being iterated.
llvm-svn: 110610
|
|
|
|
|
|
| |
id's protocols. Fixes radar 8154220.
llvm-svn: 110583
|
|
|
|
|
|
|
|
| |
an lvalue of another, compatible Objective-C object type (e.g., a
subclass). Introduce a new initialization sequence step kind to
describe this binding, along with a new cast kind. Fixes PR7741.
llvm-svn: 110513
|
|
|
|
|
|
| |
vectors, from Anton Yartsev!
llvm-svn: 110437
|
|
|
|
|
|
| |
for radar 8258797.
llvm-svn: 110047
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 109797
|
|
|
|
|
|
| |
early codegen/deserialization.
llvm-svn: 109796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenModule::MayDeferGeneration into a new function,
DeclIsRequiredFunctionOrFileScopedVar.
This is essentially a CodeGen predicate that is also needed by the PCH mechanism to determine whether a decl
needs to be deserialized during PCH loading for codegen purposes.
Since this logic is shared by CodeGen and the PCH mechanism, move it to the ASTContext,
thus CodeGenModule's GetLinkageForFunction/GetLinkageForVariable and the GVALinkage enum is moved out of CodeGen.
This fixes current (and avoids future) codegen-from-PCH bugs.
llvm-svn: 109784
|
|
|
|
|
|
|
| |
qualifiers) when checking a K&R function definition against a previous
prototype. Fixes <rdar://problem/8193107>.
llvm-svn: 109751
|
|
|
|
| |
llvm-svn: 109375
|
|
|
|
|
|
|
|
|
|
|
| |
them as such. Type::is(Signed|Unsigned|)IntegerType() now return false
for vector types, and new functions
has(Signed|Unsigned|)IntegerRepresentation() cover integer types and
vector-of-integer types. This fixes a bunch of latent bugs.
Patch from Anton Yartsev!
llvm-svn: 109229
|
|
|
|
|
|
| |
protocols (Radar 8191774).
llvm-svn: 108758
|
|
|
|
|
|
| |
suppressing copies of objects with trivial copy constructors.
llvm-svn: 107857
|
|
|
|
|
|
| |
BumpPtrAllocator
llvm-svn: 107790
|
|
|
|
|
|
|
| |
Some of the invariant checks for creating Record/Enum types don't hold true during PCH reading.
Introduce more suitable ASTContext::getRecordType() and getEnumType().
llvm-svn: 107598
|
|
|
|
|
|
| |
instantiated-from information.
llvm-svn: 107597
|
|
|
|
|
|
|
|
|
|
| |
by PCHReader.
Currently, adding it to visible decls of a PCH'ed translation unit has no effect because
adding visible decls before deserialization has no effect (the decls won't be visible).
This will be fixed in a future commit; then it will force deserialization of visible decls, so avoid pointlessly installing it.
llvm-svn: 107595
|
|
|
|
| |
llvm-svn: 107593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations for implicit default constructors, copy constructors,
copy assignment operators, and destructors. On a "simple" translation
unit that includes a bunch of C++ standard library headers, we
generate relatively few of these implicit declarations now:
4/159 implicit default constructors created
18/236 implicit copy constructors created
70/241 implicit copy assignment operators created
0/173 implicit destructors created
And, on this translation unit, this optimization doesn't really
provide any benefit. I'll do some more performance measurements soon,
but this completes the implementation work for <rdar://problem/8151045>.
llvm-svn: 107551
|
|
|
|
| |
llvm-svn: 107543
|
|
|
|
| |
llvm-svn: 107521
|
|
|
|
| |
llvm-svn: 107510
|
|
|
|
| |
llvm-svn: 107475
|
|
|
|
|
|
|
|
| |
initializing.
- Fix creation of TemplateSpecializationType.
llvm-svn: 107471
|
|
|
|
|
|
| |
with several tweaks by me.
llvm-svn: 106619
|
|
|
|
|
|
| |
declarations (implements radar 7928731).
llvm-svn: 106597
|
|
|
|
|
|
|
|
| |
allows us to have multiple copies
of ASTContext at the same time.
llvm-svn: 106258
|
|
|
|
|
|
|
| |
template name that refers to such a parameter. It's amazing that this
problem didn't surface earlier. Fixes PR7387.
llvm-svn: 106147
|
|
|
|
| |
llvm-svn: 106100
|
|
|
|
| |
llvm-svn: 106099
|
|
|
|
|
|
|
|
|
|
| |
in C++ that involve both integral and enumeration types. Convert all
of the callers to Type::isIntegralType() that are meant to work with
both integral and enumeration types over to
Type::isIntegralOrEnumerationType(), to prepare to eliminate
enumeration types as integral types.
llvm-svn: 106071
|
|
|
|
|
|
| |
from its canonical type.
llvm-svn: 105912
|
|
|
|
| |
llvm-svn: 105820
|
|
|
|
| |
llvm-svn: 105818
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case of an elaborated-type-specifier like 'typename A<T>::foo', and
DependentTemplateSpecializationType represents the case of an
elaborated-type-specifier like 'typename A<T>::template B<T>'. The TypeLoc
representation of a DependentTST conveniently exactly matches that of an
ElaboratedType wrapping a TST.
Kill off the explicit rebuild methods for RebuildInCurrentInstantiation;
the standard implementations work fine because the nested name specifier
is computable in the newly-entered context.
llvm-svn: 105801
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being a subsequence of another standard conversion sequence. Instead
of requiring exact type equality for the second conversion step,
require type *similarity*, which is type equality with cv-qualifiers
removed at all levels. This appears to match the behavior of EDG and
VC++ (albeit not GCC), and feels more intuitive. Big thanks to John
for the line of reasoning that supports this change: since
cv-qualifiers are orthogonal to the second conversion step, we should
ignore them in the type comparison.
llvm-svn: 105678
|
|
|
|
|
|
|
|
|
| |
structures wouldn't have
their associated memory destroyed when using a BumpPtrAllocator. These objects internally use
a DenseMap.
llvm-svn: 105659
|
|
|
|
|
|
| |
This is never null, but the associated type might be.
llvm-svn: 105503
|
|
|
|
| |
llvm-svn: 105500
|
|
|
|
|
|
|
| |
was given. Remove some unnecessary accounting from BlockScopeInfo. Handle
typedef'ed function types until such time as we decide not.
llvm-svn: 105478
|