| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
implicit ImportDecl in the translation unit to record the presence of
the import.
llvm-svn: 145727
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(sub)module, all of the names may be hidden, just the macro names may
be exposed (for example, after the preprocessor has seen the import of
the module but the parser has not), or all of the names may be
exposed. Importing a module makes its names, and the names in any of
its non-explicit submodules, visible to name lookup (transitively).
This commit only introduces the notion of name visible and marks
modules and submodules as visible when they are imported. The actual
name-hiding logic in the AST reader will follow (along with test cases).
llvm-svn: 145586
|
| |
|
|
|
|
|
|
|
| |
library, since modules cut across all of the libraries. Rename
serialization::Module to serialization::ModuleFile to side-step the
annoying naming conflict. Prune a bunch of ModuleMap.h includes that
are no longer needed (most files only needed the Module type).
llvm-svn: 145538
|
| |
|
|
| |
llvm-svn: 145514
|
| |
|
|
|
|
|
|
|
|
| |
callback client to suggest an alternative search path and after we
complain when the included file can't be found. The former can't be
tested in isolation, the latter doesn't actually matter (because we
won't make a module suggestion if no header is available). However,
the flow is better this way.
llvm-svn: 145502
|
| |
|
|
| |
llvm-svn: 145501
|
| |
|
|
|
|
| |
an #include/#import as a module import.
llvm-svn: 145500
|
| |
|
|
|
|
|
| |
top-level module name to a module path (e.g., std.vector). We're still
missing a number of pieces for this actually to do something.
llvm-svn: 145462
|
| |
|
|
|
|
| |
from Jason Haslam!
llvm-svn: 145012
|
| |
|
|
|
|
|
| |
preprocess/parse a header, report back with an actual module (which
may be a submodule) rather than just the name of the module.
llvm-svn: 144925
|
| |
|
|
|
|
|
| |
public. Add a __private_macro__ directive to hide a macro, similar to
the __module_private__ declaration specifier.
llvm-svn: 142188
|
| |
|
|
|
|
|
|
| |
This also adds a -Wc++98-compat-pedantic for warning on constructs which would
be diagnosed by -std=c++98 -pedantic (that is, it warns even on C++11 features
which we enable by default, with no warning, in C++98 mode).
llvm-svn: 142034
|
| |
|
|
| |
llvm-svn: 141596
|
| |
|
|
|
|
|
|
|
|
|
| |
CoreFoundation object-transfer properties audited, and add a #pragma
to cause them to be automatically applied to functions in a particular
span of code. This has to be implemented largely in the preprocessor
because of the requirement that the region be entirely contained in
a single file; that's hard to impose from the parser without registering
for a ton of callbacks.
llvm-svn: 140846
|
| |
|
|
|
|
| |
Patch by Jason Haslam!
llvm-svn: 140612
|
| |
|
|
| |
llvm-svn: 140478
|
| |
|
|
|
|
|
| |
#include or #import direcctives of framework headers into module
imports of the corresponding framework module.
llvm-svn: 139860
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.
Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.
Fixes rdar://10056932&8319466
llvm-svn: 139086
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 138257
|
| |
|
|
| |
llvm-svn: 136210
|
| |
|
|
| |
llvm-svn: 135962
|
| |
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
| |
|
|
| |
llvm-svn: 134996
|
| |
|
|
|
|
| |
file. rdar://9745065
llvm-svn: 134919
|
| |
|
|
|
|
|
| |
(SourceManager::createFileID cannot return an invalid file ID).
Also update a comment to reflect this.
llvm-svn: 134168
|
| |
|
|
|
|
| |
use the deprecated forms of llvm::StringMap::GetOrCreateValue().
llvm-svn: 133515
|
| |
|
|
|
|
| |
rdar://9475098.
llvm-svn: 131788
|
| |
|
|
|
|
|
|
|
| |
includes get resolved, especially when they are found relatively to
another include file. We also try to get it working for framework
includes, but that part of the code is untested, as I don't have a code
base that uses it.
llvm-svn: 130246
|
| |
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clients to observe the exact path through which an #included file was
located. This is very useful when trying to record and replay inclusion
operations without it beind influenced by the aggressive caching done
inside the FileManager to avoid redundant system calls and filesystem
operations.
The work to compute and return this is only done in the presence of
callbacks, so it should have no effect on normal compilation.
Patch by Manuel Klimek.
llvm-svn: 127742
|
| |
|
|
|
|
|
|
| |
The previous name was inaccurate as this token in fact appears at
the end of every preprocessing directive, not just macro definitions.
No functionality change, except for a diagnostic tweak.
llvm-svn: 126631
|
| |
|
|
| |
llvm-svn: 126221
|
| |
|
|
| |
llvm-svn: 126220
|
| |
|
|
|
|
|
|
| |
duplicate
definition by command line options. Fixes rdar://8875916.
llvm-svn: 123767
|
| |
|
|
|
|
| |
that contains the ## operator.
llvm-svn: 122946
|
| |
|
|
|
|
|
|
| |
receives a PPCallback.
Patch by Richard Smith.
llvm-svn: 122755
|
| |
|
|
|
|
|
|
|
| |
new gcc warning that complains on self-assignments and
self-initializations. Fix one bug found by the warning, in which one
clang::OverloadCandidate constructor failed to initialize its
FunctionTemplate member.
llvm-svn: 122459
|
| |
|
|
| |
llvm-svn: 122394
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
|
| |
|
|
|
|
|
| |
better to actually produce a decent set of completions by checking the
system include paths, but not today. Fixes PR8744.
llvm-svn: 121431
|
| |
|
|
|
|
|
|
|
|
|
| |
than a Token that holds the same information all in one easy-to-use
package. There's no technical reason to prefer the former -- the
information comes from a Token originally -- and it's clumsier to use,
so I've changed the code to use tokens everywhere.
Approved by clattner
llvm-svn: 119845
|
| |
|
|
|
|
|
| |
SourceManager::getPresumedLoc(), so that we don't try to make use of
an invalid presumed location. Doing so can cause crashes.
llvm-svn: 118885
|
| |
|
|
|
|
|
|
|
|
|
| |
The callback info for #if/#elif is not great -- ideally it would give
us a list of tokens in the #if, or even better, a little parse tree.
But that's a lot more work. Instead, clients can retokenize using
Lexer::LexFromRawLexer().
Reviewed by nlewycky.
llvm-svn: 118318
|
| |
|
|
|
|
|
|
|
| |
inclusion directives, keeping track of every #include, #import,
etc. in the translation unit. We keep track of the source location and
kind of the inclusion, how the file name was spelled, and the
underlying file to which the inclusion resolved.
llvm-svn: 116952
|
| |
|
|
|
|
|
|
|
| |
Now MICache is a linked list (per the FIXME), where we tradeoff between MacroInfo objects being in MICache
and MIChainHead. MacroInfo objects in the MICache chain are already "Destroy()'ed", so they can be reused. When
inserting into MICache, we need to remove them from the regular linked list so that they aren't destroyed more than
once.
llvm-svn: 116869
|
| |
|
|
|
|
| |
Preprocessor.
llvm-svn: 116864
|
| |
|
|
|
|
|
|
|
| |
The problem was not the management of MacroInfo objects, but that when we recycle them
via the MICache the memory of the underlying SmallVector (within MacroInfo) was not getting
released. This is because objects stashed into MICache simply are reused with a placement
new, and never have their destructor called.
llvm-svn: 116862
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the Preprocessor maintain them in a linked
list of allocated MacroInfos. This requires only 1 extra pointer per MacroInfo object, and allows us to blow them
away in one place. This fixes an elusive memory leak with MacroInfos (whose exact location I couldn't still figure
out despite substantial digging).
Fixes <rdar://problem/8361834>.
llvm-svn: 116842
|