to match the rest of their brethren and reformat the bits that need it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244186 91177308-0d34-0410-b5e6-96231b3b80d8

- introduces a new cc1 option -fmodule-format=[raw,obj]
  with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
  a PCHContainerReader.

Thanks to Richard Smith for reviewing this patch!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242499 91177308-0d34-0410-b5e6-96231b3b80d8

A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.

The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.

rdar://problem/20091852

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240225 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r236422, effectively reapplying r236419.  ASan
helped me diagnose the problem: the non-leaking logic would free the
ASTConsumer before freeing Sema whenever `isCurrentASTFile()`, causing a
use-after-free in `Sema::~Sema()`.

This version unconditionally frees Sema and the ASTContext before
freeing the ASTConsumer.  Without the fix, these were either being freed
before the ASTConsumer was freed or leaked after, but they were always
spiritually released so this isn't really a functionality change.

I ran all of check-clang with ASan locally this time, so I'm hoping
there aren't any more problems lurking.

Original commit message:

    Try again to plug a leak that's been around since at least r128011
    after coming across the FIXME.  Nico Weber tried something similar
    in r207065 but had to revert in r207070 due to a bot failure.

    The build failure isn't visible anymore so I'm not sure what went
    wrong.  I'm doing this slightly differently -- when not
    -disable-free I'm still resetting the members (just not leaking
    them) -- so maybe it will work out this time?  Tests pass locally,
    anyway.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236424 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r236419, since it caused some bots to fail.  On:

http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/26124
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/35086

these tests:

FAIL: Clang::import-decl.cpp
FAIL: Clang::floating-literal.c
FAIL: Clang::x86_64-linux-android.c

fail with this output:

Command Output (stderr):
--
Stack dump:
0.  Program arguments: /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/clang -cc1 -internal-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../lib/clang/3.7.0/include -nostdsysteminc -ast-print -x ast -
/var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/tools/clang/test/Modules/Output/import-decl.cpp.script: line 3:  9665 Segmentation fault      (core dumped) /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/clang -cc1 -internal-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../lib/clang/3.7.0/include -nostdsysteminc -ast-print -x ast - < /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/tools/clang/test/Modules/Output/import-decl.cpp.tmp.ast
      9666 Done                    | /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/FileCheck /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.src/tools/clang/test/Modules/import-decl.cpp

--

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236422 91177308-0d34-0410-b5e6-96231b3b80d8

Try again to plug a leak that's been around since at least r128011 after
coming across the FIXME.  Nico Weber tried something similar in r207065
but had to revert in r207070 due to a bot failure.

The build failure isn't visible anymore so I'm not sure what went wrong.
I'm doing this slightly differently -- when not -disable-free I'm still
resetting the members (just not leaking them) -- so maybe it will work
out this time?  Tests pass locally, anyway.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236419 91177308-0d34-0410-b5e6-96231b3b80d8

clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236400 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
The patch is generated using clang-tidy misc-use-override check.

This command was used:

  tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
    -checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix

Reviewers: dblaikie

Reviewed By: dblaikie

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D8926

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234678 91177308-0d34-0410-b5e6-96231b3b80d8

Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.

There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while 
SmallString do not. We may wish to change this, but it may introduce
ambiguity.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232622 91177308-0d34-0410-b5e6-96231b3b80d8

the one in the current compiler invocation. If they differ reject the PCH.

This protects against the badness occurring from getting modules loaded from different module caches (see crashes).

rdar://19889860

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229909 91177308-0d34-0410-b5e6-96231b3b80d8

produce diagnostics with source locations before the diagnostics system is
ready for them.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226882 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220731 91177308-0d34-0410-b5e6-96231b3b80d8

Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.

This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220359 91177308-0d34-0410-b5e6-96231b3b80d8

Add support for the static analyzer to synthesize function implementations from external model files.

Currently the analyzer lazily models some functions using 'BodyFarm',
which constructs a fake function implementation that the analyzer
can simulate that approximates the semantics of the function when
it is called.  BodyFarm does this by constructing the AST for
such definitions on-the-fly.  One strength of BodyFarm
is that all symbols and types referenced by synthesized function
bodies are contextual adapted to the containing translation unit.
The downside is that these ASTs are hardcoded in Clang's own
source code.

A more scalable model is to allow these models to be defined as source
code in separate "model" files and have the analyzer use those
definitions lazily when a function body is needed.  Among other things,
it will allow more customization of the analyzer for specific APIs
and platforms.

This patch provides the initial infrastructure for this feature.
It extends BodyFarm to use an abstract API 'CodeInjector' that can be
used to synthesize function bodies.  That 'CodeInjector' is
implemented using a new 'ModelInjector' in libFrontend, which lazily
parses a model file and injects the ASTs into the current translation
unit.  

Models are currently found by specifying a 'model-path' as an
analyzer option; if no path is specified the CodeInjector is not
used, thus defaulting to the current behavior in the analyzer.

Models currently contain a single function definition, and can
be found by finding the file <function name>.model.  This is an
initial starting point for something more rich, but it bootstraps
this feature for future evolution.

This patch was contributed by Gábor Horváth as part of his
Google Summer of Code project.

Some notes:

- This introduces the notion of a "model file" into
  FrontendAction and the Preprocessor.  This nomenclature
  is specific to the static analyzer, but possibly could be
  generalized.  Essentially these are sources pulled in
  exogenously from the principal translation.

  Preprocessor gets a 'InitializeForModelFile' and
  'FinalizeForModelFile' which could possibly be hoisted out
  of Preprocessor if Preprocessor exposed a new API to
  change the PragmaHandlers and some other internal pieces.  This
  can be revisited.

  FrontendAction gets a 'isModelParsingAction()' predicate function
  used to allow a new FrontendAction to recycle the Preprocessor
  and ASTContext.  This name could probably be made something
  more general (i.e., not tied to 'model files') at the expense
  of losing the intent of why it exists.  This can be revisited.

- This is a moderate sized patch; it has gone through some amount of
  offline code review.  Most of the changes to the non-analyzer
  parts are fairly small, and would make little sense without
  the analyzer changes.

- Most of the analyzer changes are plumbing, with the interesting
  behavior being introduced by ModelInjector.cpp and
  ModelConsumer.cpp.

- The new functionality introduced by this change is off-by-default.
  It requires an analyzer config option to enable.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216550 91177308-0d34-0410-b5e6-96231b3b80d8

After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215323 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215320 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215319 91177308-0d34-0410-b5e6-96231b3b80d8

This allows using EndOfMainFile from a PPCallback to access data from the
action. The pattern of PPCallback referencing an action is common in clang-tidy.

Differential Revision: http://reviews.llvm.org/D4773

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215145 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r213307.

Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213325 91177308-0d34-0410-b5e6-96231b3b80d8

(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213307 91177308-0d34-0410-b5e6-96231b3b80d8

  - Plugins don't need to export _ZN4llvm8Registry*.
  - Win32.DLL cannot merge common symbols among DLLs. Static members in llvm::Registry should be instantiated in a parent.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212821 91177308-0d34-0410-b5e6-96231b3b80d8

This doesn't need to be in the headers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212451 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210802 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210780 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209389 91177308-0d34-0410-b5e6-96231b3b80d8

ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.

This works as follows:
 * The 'most recent' pointer on a canonical declaration grows a pointer to the
   external AST source and a generation number (space- and time-optimized for
   the case where there is no external source).
 * Each time the 'most recent' pointer is queried, if it has an external source,
   we check whether it's up to date, and update it if not.
 * The ancillary data stored on the canonical declaration is allocated lazily
   to avoid filling it in for declarations that end up being non-canonical.
   We'll still perform a redundant (ASTContext) allocation if someone asks for
   the most recent declaration from a decl before setPreviousDecl is called,
   but such cases are probably all bugs, and are now easy to find.

Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.

Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.

Early performance benchmarks show that this makes no measurable difference to 
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209046 91177308-0d34-0410-b5e6-96231b3b80d8

Use this to fix the leak of DeserializedDeclsDumper and DeserializedDeclsChecker
in FrontendAction (found by LSan), PR19560.

The "delete this" bool is necessary because both PCHGenerator and ASTUnit
return the same object from both getDeserializationListener() and
getASTMutationListener(), so ASTReader can't just have a unique_ptr.

It's also not possible to just let FrontendAction (or CompilerInstance) own
these listeners due to lifetime issues (see comments on PR19560).

Finally, ASTDeserializationListener can't easily be refcounted, since several of
the current listeners are allocated on the stack.

Having this bool isn't ideal, but it's a pattern that's used in other places in
the codebase too, and it seems better than leaking.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208277 91177308-0d34-0410-b5e6-96231b3b80d8

http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/22506


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207070 91177308-0d34-0410-b5e6-96231b3b80d8

Also update a comment to match a code change that was done in r110978.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207065 91177308-0d34-0410-b5e6-96231b3b80d8

Should suppress several LSan reports.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207056 91177308-0d34-0410-b5e6-96231b3b80d8

This allows code indexing, etc. to use the VFS in the same way as the
compiler.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206309 91177308-0d34-0410-b5e6-96231b3b80d8

To differentiate between two modules with the same name, we will
consider the path the module map file that they are defined by* part of
the ‘key’ for looking up the precompiled module (pcm file).
Specifically, this patch renames the precompiled module (pcm) files from
  cache-path/<module hash>/Foo.pcm
to
  cache-path/<module hash>/Foo-<hash of module map path>.pcm

In addition, I’ve taught the ASTReader to re-resolve the names of
imported modules during module loading so that if the header search
context changes between when a module was originally built and when it
is loaded we can rebuild it if necessary.  For example, if module A
imports module B

first time:
clang -I /path/to/A -I /path/to/B ...

second time:
clang -I /path/to/A -I /different/path/to/B ...

will now rebuild A as expected.

* in the case of inferred modules, we use the module map file that
allowed the inference, not the __inferred_module.map file, since the
inferred file path is the same for every inferred module.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206201 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203758 91177308-0d34-0410-b5e6-96231b3b80d8

This compiles cleanly with lldb/lld/clang-tools-extra/llvm.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203279 91177308-0d34-0410-b5e6-96231b3b80d8

This is a precursor to moving to std::unique_ptr.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203275 91177308-0d34-0410-b5e6-96231b3b80d8

avoid warning for unused macros.

rdar://15034698

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203213 91177308-0d34-0410-b5e6-96231b3b80d8

With r197755 we started reading the contents of buffer file entries, but the
buffers may point to ASTReader blobs that have been disposed.

Fix this by having the CompilerInstance object keep a reference to the ASTReader
as well as having the ASTContext keep reference to the ExternalASTSource.

This was very difficult to construct a test case for.
rdar://16149782

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202346 91177308-0d34-0410-b5e6-96231b3b80d8

Reads the description of a virtual filesystem from a file and overlays
it over the real file system.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202176 91177308-0d34-0410-b5e6-96231b3b80d8

Previously reverted in r201755 due to causing an assertion failure.

I've removed the offending assertion, and taught the CompilerInstance to
create a default virtual file system inside createFileManager. In the
future, we should be able to reach into the CompilerInvocation to
customize this behaviour without breaking clients that don't care.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201818 91177308-0d34-0410-b5e6-96231b3b80d8

in our internal build bots.

This reverts commits 201618, 201635, 201636, 201639, 201685, 201691, and 201696.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201755 91177308-0d34-0410-b5e6-96231b3b80d8