This is causing a huge pile of buildbot failures.


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

Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.

This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.

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


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

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <claprix@yandex.ru>

Differential Revision: https://reviews.llvm.org/D20100

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

No functionality change intended, maybe a tiny performance improvement.

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

  - Externalize the registry.
  - Update libdeps.

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

option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.

This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.


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

This reduces the number of .cpp files needed to be rebuilt after
touching OnDiskHashTable from 120 to 21 for me.

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

Summary: It breaks the build for the ASTMatchers

Subscribers: klimek, cfe-commits

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

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

Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

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

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

+couple more of double-negated !SourceLocation.isInvalid() unfixed in r249228.



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

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

 * adds -aux-triple option to specify target triple
 * propagates aux target info to AST context and Preprocessor
 * pulls in target specific preprocessor macros.
 * pulls in target-specific builtins from aux target.
 * sets appropriate host or device attribute on builtins.

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

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

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

So, iterate over the list of macros mentioned in modules, and make sure those
are in the master table.

This isn't particularly efficient, but hopefully it's something that isn't
done too often.

PR23929 and rdar://problem/21480635

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

visibility is enabled) or leave and re-enter it, restore the macro and module
visibility state from last time we were in that submodule.

This allows mutually-#including header files to stand a chance at being
modularized with local visibility enabled.


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

This, in preparation for the introduction of more new keywords in the
implementation of the C++ language, generalizes the support for future keyword
compat diagnostics (e.g., diag::warn_cxx11_keyword) by extending the
applicability of the relevant property in IdentifierTable with appropriate
renaming.

Patch by Hubert Tong!


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

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

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

should not export the macro.

... at least, not unless we have local submodule visibility enabled.


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

It has no place there; it's not a property of the Module, and it makes
restoring the visibility set when we leave a submodule more difficult.


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

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

Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).

No functionality change intended.


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

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

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

the active module macros at the point of definition, rather than reconstructing
it from the macro history. No functionality change intended.


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

Previously we'd defer this determination until writing the AST, which doesn't
allow us to use this information when building other submodules of the same
module. This change also allows us to use a uniform mechanism for writing
module macro records, independent of whether they are local or imported.


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

Macro names that got undefined inside a module may not have their MacroInfo set.

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

in debugger mode) to accept @import declarations
and pass them to the debugger.  

In the preprocessor, accept import declarations
if the debugger is enabled, but don't actually
load the module, just pass the import path on to 
the preprocessor callbacks.

In the Objective-C parser, if it sees an import
declaration in statement context (usual for LLDB),
ignore it and return a NullStmt.


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

rather than trying to extract this information from the FileEntry after the
fact.

This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.


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

[libclang] If the code-completion point is inside the preamble, adjust the position at the beginning of the file after the preamble.
    
Otherwise we will not hit the code-completion point.


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

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

Follow up to r217656

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

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

Unique_ptr creation stil needs to be moved earlier at some of the call sites.

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

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

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

Overload SourceManager::overrideFileContents so that unconditionally passing ownership is explicitly done using unique_ptr.

Only those callers who are dynamically passing ownership should need the
3 argument form. Those accepting the default ("do pass ownership")
should do so explicitly with a unique_ptr now.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216585 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

And in the process, discover that FileManager::removeStatCache had a
double-delete when removing an element from the middle of the list (at
the beginning or the end of the list, there was no problem) and add a
unit test to exercise the code path (which successfully crashed when run
(with modifications to match the old API) without this patch applied)

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