| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
and language-specific initialization. Use this to allow ASTUnit to
create a preprocessor object *before* loading the AST file. No actual
functionality change.
llvm-svn: 138983
|
| |
|
|
|
|
| |
in the face of buffering C++/ObjC method bodies.
llvm-svn: 138972
|
| |
|
|
|
|
|
|
|
| |
LangOptions, rather than making distinct copies of
LangOptions. Granted, LangOptions doesn't actually get modified, but
this will eventually make it easier to construct ASTContext and
Preprocessor before we know all of the LangOptions.
llvm-svn: 138959
|
| |
|
|
|
|
|
|
|
|
|
| |
include guards don't show up as macro definitions in every translation
unit that imports a module. Macro definitions can, however, be
exported with the intentionally-ugly #__export_macro__
directive. Implement this feature by not even bothering to serialize
non-exported macros to a module, because clients of that module need
not (should not) know that these macros even exist.
llvm-svn: 138943
|
| |
|
|
|
|
| |
on Windows.
llvm-svn: 138880
|
| |
|
|
|
|
|
|
| |
existing practice with Python extension modules. Not that Python
extension modules should be using a double-underscored identifier
anyway, but...
llvm-svn: 138870
|
| |
|
|
|
|
|
|
| |
suppress it in system headers. And it is not a good idea to suppress it in system headers. (This was originally changed in r134996 to implement -MG.)
Fixes <rdar://10041960>. And also brings down the number of warnings without a flag by one :)
llvm-svn: 138842
|
| |
|
|
|
|
|
|
|
| |
collision between C99 hexfloats and C++0x user-defined literals by
giving C99 hexfloats precedence. Also, warning about user-defined
literals that conflict with hexfloats and those that have names that
are reserved by the implementation. Fixes <rdar://problem/9940194>.
llvm-svn: 138839
|
| |
|
|
|
|
|
| |
features, so clients can check for the availability of these features
even before we get around to implementing them.
llvm-svn: 138741
|
| |
|
|
|
|
|
|
|
| |
__import__ within the preprocessor, since the prior one foolishly
assumed that Preprocessor::Lex() was re-entrant. We now handle
__import__ at the top level (only), after macro expansion. This should
fix the buildbot failures.
llvm-svn: 138704
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.
llvm-svn: 138679
|
| |
|
|
|
|
| |
out-of-sync how a file is compiled. Patch by Matthias Kleine!
llvm-svn: 138580
|
| |
|
|
| |
llvm-svn: 138475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regression due
to increased calls to SourceManager::getFileID. (rdar://9992664)
Use a slightly different approach that is more efficient both in terms of speed
(no extra getFileID calls) and in SLocEntries reduction.
Comparing pre-r138129 and this patch we get:
For compiling SemaExpr.cpp reduction of SLocEntries by 26%.
For the boost enum library:
-SLocEntries -34% (note that this was -5% for r138129)
-Memory consumption -50%
-PCH size -31%
Reduced SLocEntries also benefit the hot function SourceManager::getFileID,
evident by the reduced "FileID scans".
llvm-svn: 138380
|
| |
|
|
|
|
|
|
| |
of isInFileID
since it is a bit more efficient.
llvm-svn: 138379
|
| |
|
|
| |
llvm-svn: 138378
|
| |
|
|
|
|
| |
SourceLocation.
llvm-svn: 138377
|
| |
|
|
|
|
| |
the extra SourceManager::getFileID call.
llvm-svn: 138376
|
| |
|
|
| |
llvm-svn: 138257
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently getMacroArgExpandedLocation is very inefficient and for the case
of a location pointing at the main file it will end up checking almost all of
the SLocEntries. Make it faster:
-Use a map of macro argument chunks to their expanded source location. The map
is for a single source file, it's stored in the file's ContentCache and lazily
computed, like the source lines cache.
-In SLocEntry's FileInfo add an 'unsigned NumCreatedFIDs' field that keeps track
of the number of FileIDs (files and macros) that were created during preprocessing
of that particular file SLocEntry. This is useful when computing the macro argument
map in skipping included files while scanning for macro arg FileIDs that lexed from
a specific source file. Due to padding, the new field does not increase the size
of SLocEntry.
llvm-svn: 138225
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
for tokens that are lexed consecutively from the same FileID, instead of creating
a SLocEntry for each token. e.g for
assert(foo == bar);
there will be a single SLocEntry for the "foo == bar" chunk and locations
for the 'foo', '==', 'bar' tokens will point inside that chunk.
For parsing SemaExpr.cpp, this reduced the number of SLocEntries by 25%.
llvm-svn: 138129
|
| |
|
|
|
|
| |
getExpansionLocForMacroDefLoc, no functionality change.
llvm-svn: 138128
|
| |
|
|
| |
llvm-svn: 138031
|
| |
|
|
| |
llvm-svn: 137973
|
| |
|
|
|
|
| |
of expansion (for function macros it includes the right paren).
llvm-svn: 137909
|
| |
|
|
| |
llvm-svn: 137795
|
| |
|
|
| |
llvm-svn: 137430
|
| |
|
|
| |
llvm-svn: 137301
|
| |
|
|
| |
llvm-svn: 137298
|
| |
|
|
| |
llvm-svn: 137039
|
| |
|
|
|
|
| |
because we don't support them yet.
llvm-svn: 137027
|
| |
|
|
| |
llvm-svn: 136788
|
| |
|
|
|
|
|
|
|
|
|
| |
1. Be more tolerant of comments in -CC (comment-preserving) mode. We were missing a few cases.
2. Make sure to expand the second FOO in "#if defined FOO FOO". (See also
r97253, which addressed the case of "#if defined(FOO FOO".)
Fixes PR10286.
llvm-svn: 136748
|
| |
|
|
| |
llvm-svn: 136561
|
| |
|
|
|
|
|
| |
libstdc++ hack has reverted these type traits to keywords. Icky, but
fixes <rdar://problem/9836262>.
llvm-svn: 136560
|
| |
|
|
|
|
|
| |
a fallback, if normal header search fails. Another attempt at
<rdar://problem/9824020>.
llvm-svn: 136557
|
| |
|
|
|
|
|
| |
for quoted header lookup when dealing with not-yet-installed
frameworks. Fixes <rdar://problem/9824020>.
llvm-svn: 136331
|
| |
|
|
|
|
| |
after the given location. (It is a generalized version of trans::findLocationAfterSemi from ArcMigrate, which will be changed to use the Lexer utility).
llvm-svn: 136268
|
| |
|
|
| |
llvm-svn: 136239
|
| |
|
|
| |
llvm-svn: 136238
|
| |
|
|
| |
llvm-svn: 136237
|
| |
|
|
| |
llvm-svn: 136210
|
| |
|
|
|
|
|
| |
This required converting the StringMaps to use a BumpPtrAllocator. I measured the
compile time and saw no observable regression.
llvm-svn: 136190
|
| |
|
|
|
|
|
|
|
|
| |
PreprocessingRecord::getTotalMemory().
Most of the memory was already reported; but now we report more memory from side data structures.
Fixes <rdar://problem/9379717>.
llvm-svn: 136150
|
| |
|
|
|
|
|
|
| |
etc. With this I think essentially all of the SourceManager APIs are
converted. Comments and random other bits of cleanup should be all thats
left.
llvm-svn: 136057
|
| |
|
|
|
|
|
|
|
| |
and various other 'expansion' based terms. I've tried to reformat where
appropriate and catch as many references in comments but I'm going to do
several more passes. Also I've tried to expand parameter names to be
more clear where appropriate.
llvm-svn: 136056
|
| |
|
|
| |
llvm-svn: 136054
|
| |
|
|
| |
llvm-svn: 135962
|
| |
|
|
|
|
| |
getImmediateExpansionRange.
llvm-svn: 135960
|
| |
|
|
| |
llvm-svn: 135915
|