ranges as part of the ASTContext. This code is not and was never used,
but contributes ~250k to the size of the Cocoa.h precompiled
header.
llvm-svn: 99007
record (which includes all macro instantiations and definitions). As
with all lay deserialization, this introduces a new external source
(here, an external preprocessing record source) that loads all of the
preprocessed entities prior to iterating over the entities.
The preprocessing record is an optional part of the precompiled header
that is disabled by default (enabled with
-detailed-preprocessing-record). When the preprocessor given to the
PCH writer has a preprocessing record, that record is written into the
PCH file. When the PCH reader is given a PCH file that contains a
preprocessing record, it will be lazily loaded (which, effectively,
implicitly adds -detailed-preprocessing-record). This is the first
case where we have sections of the precompiled header that are
added/removed based on a compilation flag, which is
unfortunate. However, this data consumes ~550k in the PCH file for
Cocoa.h (out of ~9.9MB), and there is a non-trivial cost to gathering
this detailed preprocessing information, so it's too expensive to turn
on by default. In the future, we should investigate a better encoding
of this information.
llvm-svn: 99002
presence or absence of header map arguments when using the precompiled
header would cause Clang to get confused about which headers had
already been included/imported, along with their controlling
macros. The fundamental problem is that the serialization of the
header search information was relying on the UIDs of FileEntry objects
at PCH generation time and PCH load time to be equivalent, which
effectively means that we had to probe the same files in the same
order. Differing header map arguments caused an extra FileEntry
lookup, but it's easy to imagine other minor command-line arguments
triggering this problem.
Header-search information is now encoded along with the
source-location entry for a file, so that we register information
about a file's properties as a header at the same time we create the
FileEntry for that file.
Fixes <rdar://problem/7743243>.
llvm-svn: 98636
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
llvm-svn: 98134
This is a non-fragile-abi feature only. Since it
breaks existing code, it is currently placed under
-fobjc-nonfragile-abi2 option for test purposes only
until further notice. WIP.
llvm-svn: 95685
have it return a StringRef instead of an integer (to be more VCS
agnostic).
(2) Add getClangFullRepositoryVersion(), which contains an
amalgamation of the repository name and the revision.
(3) Change PCH to only emit the string returned by
getClangFullRepositoryVersion() instead of also emitting the value
of getClangSubversionRevision() (which has been removed). This is
functionally equivalent.
More cleanup to version string generation pending...
llvm-svn: 94231
definitions from a precompiled header. This ensures that
code-completion with macro names behaves the same with or without
precompiled headers.
llvm-svn: 92497
This implements a new flag -fcatch-undefined-behavior. The flag turns
on additional runtime checks for:
T a[I];
a[i] abort when i < 0 or i >= I.
Future stuff includes shifts by >= bitwidth amounts.
llvm-svn: 91198
type and fixes a long-standing code gen. crash reported in
at least two PRs and a radar. (radar 7405040 and pr5025).
There are couple of remaining issues that I would like for
Ted. and Doug to look at:
Ted, please look at failure in Analysis/MissingDealloc.m.
I have temporarily added an expected-warning to make the
test pass. This tests has a declaration of 'SEL' type which
may not co-exist with the new changes.
Doug, please look at a FIXME in PCHWriter.cpp/PCHReader.cpp.
I think the changes which I have ifdef'ed out are correct. They
need be considered for in a few Indexer/PCH test cases.
llvm-svn: 89561
the front-end (as far as the preprocessor goes), follow the usual logic of
inserting the (original include path) name into the predefines buffer. This
pushes the responsibility for handling this to PCH instead of the front-end. In
PCH this requires being a little more clever when we diff the predefines
buffers.
Neither of these solutions are particularly great, I think what we eventually
should do is something like gcc where we insert a special marker to indicate the
PCH file, but then run the preprocessor as usual. This would be clearer and
would allow us to drop the overly clever predefines handling.
llvm-svn: 86806
tons of std::string trashing. I plan to move this and other fun string munging
utilities to a StringRefExtras.h at some point if no one beats me to it.
On a synthetic benchmark on x86_64, llvm-gcc actually generates code thats 10%
faster using the StringRef version. gcc miscompiles the synthetic benchmark,
which I'm crossing my fingers and hoping won't happen here. clang compiles the
sythetic benchmark correctly (wootness), but the StringRef version is
slower. Silly clang.
llvm-svn: 86799
parameters. Rather than storing them as either declarations (for the
non-dependent case) or expressions (for the dependent case), we now
(always) store them as TemplateNames.
The primary change here is to add a new kind of TemplateArgument,
which stores a TemplateName. However, making that change ripples to
every switch on a TemplateArgument's kind, also affecting
TemplateArgumentLocInfo/TemplateArgumentLoc, default template
arguments for template template parameters, type-checking of template
template arguments, etc.
This change is light on testing. It should fix several pre-existing
problems with template template parameters, such as:
- the inability to use dependent template names as template template
arguments
- template template parameter default arguments cannot be
instantiation
However, there are enough pieces missing that more implementation is
required before we can adequately test template template parameters.
llvm-svn: 86777
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
llvm-svn: 85500
identifier. This caused a crash when reading PCH files that contained
long identifier names.
The issue is that 'StrLenPtr' was previously a 'const char *', meaning
the byte loaded from it would be interpretted as a signed integer. If
the topmost bit was set, conversion to 'unsigned' would extend that
bit, causing an overflow.
The solution is to make 'StrLenPtr' an 'unsigned char *', always
treating the value as an unsigned integer.
This fixes: <rdar://problem/7328900>
llvm-svn: 84925
the DeclaratorInfo, one for semantic analysis), just build a single type whose
canonical type will reflect the semantic analysis (assuming the type is
well-formed, of course).
To make that work, make a few changes to the type system:
* allow the nominal pointee type of a reference type to be a (possibly sugared)
reference type. Also, preserve the original spelling of the reference type.
Both of these can be ignored on canonical reference types.
* Remove ObjCProtocolListType and preserve the associated source information on
the various ObjC TypeLocs. Preserve the spelling of protocol lists except in
the canonical form.
* Preserve some level of source type structure on parameter types, but
canonicalize on the canonical function type. This is still a WIP.
Drops code size, makes strides towards accurate source location representation,
slight (~1.7%) progression on Cocoa.h because of complexity drop.
llvm-svn: 84907
TemplateTypeParmType with the substituted type directly; instead, replace it
with a SubstTemplateTypeParmType which will note that the type was originally
written as a template type parameter. This makes it reasonable to preserve
source information even through template substitution.
Also define the new SubstTemplateTypeParmType class, obviously.
For consistency with current behavior, we stringize these types as if they
were the underlying type. I'm not sure this is the right thing to do.
At any rate, I paled at adding yet another clause to the don't-desugar 'if'
statement, so I extracted a function to do it. The new function also does
The Right Thing more often, I think: e.g. if we have a chain of typedefs
leading to a vector type, we will now desugar all but the last one.
llvm-svn: 84412
TypeLoc class names to be $(Type classname)Loc. Rewrite the visitor.
Provide skeleton implementations for all the new TypeLocs.
Handle all cases in PCH. Handle a few more cases when inserting
location information in SemaType.
It should be extremely straightforward to add new location information
to existing TypeLoc objects now.
llvm-svn: 84386
format, so that we don't end up with multiple declaration and types
blocks. Also, fix a few obscure bugs with PCH loading and generation:
- If the DeclIDs DenseMap reallocates while we are writing a
declaration (due to recursively writing other declarations), we
could end up writing a bad ID to ExternalDefinitions.
- When loading an ArrayLoc (part of DeclaratorInfo), we need to set
the size expression to NULL if no size expression was provided.
PCH -> AST rewriting is still partly broken, unfortunately.
llvm-svn: 84293
only supporting a single stat cache. The immediate benefit of this
change is that we can now generate a PCH/AST file when including
another PCH file; in the future, the chain of stat caches will likely
be useful with multiple levels of PCH files.
llvm-svn: 84263
TypeLoc records for declarations; it should not be necessary to represent it
directly in the type system.
Please complain if you were using these classes and feel you can't replicate
previous functionality using the TypeLoc API.
llvm-svn: 84222
This is used only for keeping detailed type source information for protocol references,
it should not participate in the semantics of the type system.
Its protocol list is not canonicalized.
llvm-svn: 83093
Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right; many more remain.
llvm-svn: 82705
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
This is something of a hack, since whether the reader actually did this depends on the "isConsumerInterestedIn" predicate. I think we need to rework how this works, but I need to discuss with Doug.
llvm-svn: 82111
order because it was doing so while iterating over a densemap.
There are still similar problems in other places, for example
WeakUndeclaredIdentifiers is still written to the PCH file in a nondeterminstic
order, and we emit warnings about #pragma weak in nondeterminstic order.
llvm-svn: 81236
directly in the AST. The current thinking is to create these
only in C++ mode for efficiency. But for now, they're not being
created at all; patch to follow.
This will let us do things like verify that tags match during
template instantation, as well as signal that an elaborated type
specifier was used for clients that actually care.
Optimally, the TypeLoc hierarchy should be adjusted to carry tag
location information as well.
llvm-svn: 81057
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
llvm-svn: 77510
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
llvm-svn: 76193
This removes the static data/methods on ObjCObjectPointerType while preserving the nice API (no need to fiddle with ASTContext:-).
This patch also adds Type::isObjCBuiltinType().
This should be the last fairly large patch related to recrafting the ObjC type system. The follow-on patches should be fairly small.
llvm-svn: 75808
The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches.
This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic.
By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time.
Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks.
llvm-svn: 75314
FILE type, rather than using name lookup to find FILE within the
translation unit. Within precompiled headers, FILE is treated as yet
another "special type" (like __builtin_va_list).
This change should provide a performance improvement (not verified),
since the lookup into the translation unit declaration
forces the (otherwise unneeded) construction of a large hash table.
More importantly, with precompiled headers, the construction
of that table requires deserializing most of the top-level
declarations from the precompiled header, which are then unused.
Fixes PR 4509.
llvm-svn: 74911
with a particular system root directory and can be used with a different
system root directory when the headers it depends on have been installed.
Relocatable precompiled headers rewrite the file names of the headers used
when generating the PCH file into the corresponding file names of the
headers available when using the PCH file.
Addresses <rdar://problem/7001604>.
llvm-svn: 74885
of a top-level declaration loads another top-level declaration of the
same name whose type depends on the first declaration having been
completed. This commit breaks the circular dependency by delaying
loads of top-level declarations triggered by loading a name until we
are no longer recursively loading types or declarations.
llvm-svn: 74847
declaration in the AST.
The new ASTContext::getCommentForDecl function searches for a comment
that is attached to the given declaration, and returns that comment,
which may be composed of several comment blocks.
Comments are always available in an AST. However, to avoid harming
performance, we don't actually parse the comments. Rather, we keep the
source ranges of all of the comments within a large, sorted vector,
then lazily extract comments via a binary search in that vector only
when needed (which never occurs in a "normal" compile).
Comments are written to a precompiled header/AST file as a blob of
source ranges. That blob is only lazily loaded when one requests a
comment for a declaration (this never occurs in a "normal" compile).
The indexer testbed now supports comment extraction. When the
-point-at location points to a declaration with a Doxygen-style
comment, the indexer testbed prints the associated comment
block(s). See test/Index/comments.c for an example.
Some notes:
- We don't actually attempt to parse the comment blocks themselves,
beyond identifying them as Doxygen comment blocks to associate them
with a declaration.
- We won't find comment blocks that aren't adjacent to the
declaration, because we start our search based on the location of
the declaration.
- We don't go through the necessary hops to find, for example,
whether some redeclaration of a declaration has comments when our
current declaration does not. Similarly, we don't attempt to
associate a \param Foo marker in a function body comment with the
parameter named Foo (although that is certainly possible).
- Verification of my "no performance impact" claims is still "to be
done".
llvm-svn: 74704
-Introduce 'PCHReaderListener' which is an abstract interface for getting various information from the PCHReader.
-If PCHReader is constructed without a Preprocessor, it can still load the file and invoke the callbacks of PCHReaderListener.
-If PCHReader is constructed with an initialized Preprocessor, PCHValidator is used as a PCHReaderListener to validate the contents of the PCH file against the given Preprocessor.
llvm-svn: 73741
Add a type (ObjCObjectPointerType) and remove a type (ObjCQualifiedIdType).
This large/tedious patch is just a first step. Next step is to remove ObjCQualifiedInterfaceType. After that, I will remove the magic TypedefType for 'id' (installed by Sema). This work will enable various simplifications throughout clang (when dealing with ObjC types).
No functionality change.
llvm-svn: 73649
compatible with VC++ and GCC. The codegen/mangling angle hasn't
been fully ironed out yet. Note that we accept int128_t even in
32-bit mode, unlike gcc.
llvm-svn: 70464
which eliminates the storage for IdentifierInfo in the "uninteresting
identifier" cases. Sadly, this only brought back 7k of the 500k we
lost :(
llvm-svn: 70325
line when using a PCH that were not provided when building the PCH
file. If those names were used as identifiers somewhere in the PCH
file, reject the PCH file.
llvm-svn: 70321
for identifiers to separate "interesting" from "uninteresting"
identifiers. However, to cope with compiler invocations where the
predefines buffers mismatch, we need to be able to search the complete
identifier table. Cocoa.h.pch is now about 500k larger that it used to
be :(
llvm-svn: 70320
PCH file and the predefines buffer used when including the PCH
file. We (explicitly) detect conflicting macro definitions (rejecting
the PCH file) and about missing macro definitions (they'll be
automatically pulled from the PCH file anyway).
We're missing some checking to make sure that new macro definitions
won't have any impact on the PCH file itself (e.g., #define'ing an
identifier that the PCH file used).
llvm-svn: 70316
Clang version value rather than hard-coding "1.0".
Add PCH and Clang version information into the PCH file. Reject PCH
files with the wrong version information.
llvm-svn: 70264
essentially the same thing we do with pretokenized headers. stat()
caching improves performance of the Cocoa-prefixed "Hello, World" by
45%.
llvm-svn: 70223
file. In particular, only eagerly load source location entries for
files and for the predefines buffer. Other buffers and
macro-instantiation source location entries are loaded lazily.
With the Cocoa-prefixed "Hello, World", we only load 815/26555 source
location entities. This halves the amount of user time we spend in
this "Hello, World" program with -fsyntax-only (down to .007s).
This optimization is part 1 of 2 for the source manager. This
eliminates most of the user time in loading a PCH file. We still spend
too much time initialize File structures (especially in the calls to
stat), so we need to either make the loading of source location
entries for files lazy or import the stat cache from the PTH
implementation.
llvm-svn: 70196
- Deal with the Receiver/ClassInfo shared storage in ObjCMessageExpr
- Implement PCH support for ImplicitParamDecl
- Fix the handling of the body of an ObjCMethodDecl
- Several cast -> cast_or_null fixes
- Make Selector::getIdentifierInfoForSlot work for 1-argument, NULL
selectors.
- Make Selector::getAsString() work with NULL selectors.
- Fix the names of VisitObjCAtCatchStmt and VisitObjCAtFinallyStmt
in the PCH reader and writer; these were never getting called.
At this point, all of the pch-test tests pass for C and Objective-C.
llvm-svn: 70163
necessary and iterate until all types and declarations have been
written. This reduces the Cocoa.h PCH file size by about 4% (since we
don't write types we don't need), and fixes problems where writing a
declaration generates a new type.
This doesn't seem to have any impact on performance either way.
llvm-svn: 70109
most of which are ignored. Instead, move the __COUNTER__ value out to
a PCH-level record (since it is handled eagerly) and move the header
file information into the SourceManager block (which is also,
currently, loaded eagerly).
This results in another 17% performance improvement in the
Cocoa-prefixed "Hello, World" with PCH.
llvm-svn: 70097
PCH file. In the Cocoa-prefixed "Hello, World" benchmark, this takes
us from reading 503 identifiers down to 37 and from 470 macros down to
4. It also results in an 8% performance improvement.
llvm-svn: 70094
identifier's ID. In this case, we know where the identifier's entry is
located in the hash table (it starts right before the identifier
string itself), so skip the hash table lookup and read the entry
directly. The performance improvement here is, gain, hard to quantify,
but it's the right thing to do.
llvm-svn: 70078
"interesting" identifiers (e.g., those where the IdentifierInfo has
some useful information) from "uninteresting" identifiers (where the
IdentifierInfo is just a name). This makes the hash table smaller (so
searching in it should be faster) and, when loading "uninteresting"
identifiers, we skip the lookup in the hash table.
PCH file size is slightly smaller than before (since we don't emit the
contents of the uninteresting IdentifierInfo structures). The
Cocoa.h-prefixed "Hello, World" doesn't show any speedup, although
we're getting to the point where system noise is a bit issue.
llvm-svn: 70075
allocating IdentifierInfos with a pointer into the string data stored
in the PCH file rather than having an entry in the identifier table's
string map. However, we don't actually get these savings at the
moment, because we go through the IdentifierTable when loading
identifiers from the on-disk hash table.
This commit is for record-keeping purposes only. I'll be reverting
this change (and the PCH layout tweak that preceded it) because it
appears that implementing this optimization will collide with another,
future optimization to reduce the size of the on-disk hash table for
identifiers. That optimization is likely to provide more benefit (with
less voodoo).
llvm-svn: 70070
that the PCH reader does not have to decode the VBR encoding at PCH
load time.
Also, reduce the size of the identifier offsets from 64 bits down to
32 bits. The identifier table itself isn't going to grow to more than
4GB :)
Overall, this results in a 13% speedup in the Cocoa-prefixed "Hello,
World" benchmark.
llvm-svn: 70063
blobs, so that we don't need to do any work to get these arrays into
memory at PCH load time.
This gives another 19% performance improvement to the Cocoa-prefixed
"Hello, World!".
llvm-svn: 70059
Douglas Gregor