"FileID" a concept that is now enforced by the compiler's type checker
instead of yet-another-random-unsigned floating around.
This is an important distinction from the "FileID" currently tracked by
SourceLocation. *That* FileID may refer to the start of a file or to a
chunk within it. The new FileID *only* refers to the file (and its
#include stack and eventually #line data), it cannot refer to a chunk.
FileID is a completely opaque datatype to all clients, only SourceManager
is allowed to poke and prod it.
llvm-svn: 62407
- IdentifierInfo can now (optionally) have its string data not be
co-located with itself. This is for use with PTH. This aspect is a
little gross, as getName() and getLength() now make assumptions
about a possible alternate representation of IdentifierInfo.
Perhaps we should make IdentifierInfo have virtual methods?
IdentifierTable:
- Added class "IdentifierInfoLookup" that can be used by
IdentifierTable to perform "string -> IdentifierInfo" lookups using
an auxilliary data structure. This is used by PTH.
- Perform tests show that IdentifierTable::get() does not slow down
because of the extra check for the IdentiferInfoLookup object (the
regular StringMap lookup does enough work to mitigate the impact of
an extra null pointer check).
- The upshot is that now that some IdentifierInfo objects might be
owned by the IdentiferInfoLookup object. This should be reviewed.
PTH:
- Modified PTHManager::GetIdentifierInfo to *not* insert entries in
IdentifierTable's string map, and instead create IdentifierInfo
objects on the fly when mapping from persistent IDs to
IdentifierInfos. This saves a ton of work with string copies,
hashing, and StringMap lookup and resizing. This change was
motivated because when processing source files in the PTH cache we
don't need to do any string -> IdentifierInfo lookups.
- PTHManager now subclasses IdentifierInfoLookup, allowing clients of
IdentifierTable to transparently use IdentifierInfo objects managed
by the PTH file. PTHManager resolves "string -> IdentifierInfo"
queries by doing a binary search over a sorted table of identifier
strings in the PTH file (the exact algorithm we use can be changed
as needed).
These changes lead to the following performance changes when using PTH on Cocoa.h:
- fsyntax-only: 10% performance improvement
- Eonly: 30% performance improvement
llvm-svn: 62273
its Decls in indented format. An Example:
$ cat t.cpp
class A {
int a;
void f();
};
void A::f() {
a = 3;
}
$ clang -print-decl-contexts t.cpp
[translation unit] 0x9754d7c
<typedef> __builtin_va_list
[class] A 0x9753310
<class> A 0x975ce20
<field> a
<c++ method> f
<c++ ctor> A
<c++ ctor> A
<c++ method> operator=
<c++ dtor> ~A
[c++ method] f [[0x9753310]]
Some comments: '<>' indicates a declaration, '[]' indicates a definition, '[[
]]' displays the semantic DeclContext which is different from the lexical
DeclContext. The symbols printed can definitely be changed in the future.
llvm-svn: 62136
C++ handle anonymous structs/unions in the same way. Addresses several
bugs:
<rdar://problem/6259534>
<rdar://problem/6481130>
<rdar://problem/6483159>
The test case in PR clang/1750 now passes with -fsyntax-only, but
CodeGen for inline assembler still fails.
llvm-svn: 62112
specific targets default them to on. Default blocks to on on 10.6 and later.
Add a -fblocks option that allows the user to override the target's default.
Use -fblocks in the various testcases that use blocks.
llvm-svn: 60563
converting a pointer to one Objective-C interface into a pointer to another
Objective-C interface, and conversions with 'id'. The semantics seems
to match GCC, although they seem somewhat ad hoc.
Fixed a few cases where we assumed the C++ definition of isObjectType,
but were getting the C definition, causing failures in trouble with
conversions to void pointers.
llvm-svn: 60130
were being treated as type names for non-Objective-C files.
- Other lines are just because MinimalAction didn't have access to
the LangOptions.
llvm-svn: 58498
- Split backend related consumer out into Backend.cpp, replaces
LLVMCodeGenWriter.
- Structure follows llvm-gcc to some extent.
- Still need to implement all the options which impact code
generation and the optimization passes which llvm-gcc uses at
various levels.
llvm-svn: 57936
Fix <rdar://problem/6265257> warnings for ambiguous message send swamp other warnings.
Reworked Sema::MatchTwoMethodDeclarations() to optionally match based on method size and alignment (the default in GCC). Changed Sema::LookupInstanceMethodInGlobalPool() to use this feature.
Added -Wno-struct-selector-match to driver, however didn't hook it up yet. Added a FIXME that says this.
llvm-svn: 57898
Ted Kremenek