Revert r276973 "Adjust Registry interface to not require plugins to export a registry"

Buildbot failures when building with clang -Werror. Reverting while I try to
figure this out.

llvm-svn: 277008

Reapply r276856 "Adjust Registry interface to not require plugins to export a registry"

This version has two fixes compared to the original:
* In Registry.h the template static members are instanti

Reapply r276856 "Adjust Registry interface to not require plugins to export a registry"

This version has two fixes compared to the original:
* In Registry.h the template static members are instantiated before they are
used, as clang gives an error if you do it the other way around.
* The use of the Registry template in clang-tidy is updated in the same way as
has been done everywhere else.

Original commit message:

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.

llvm-svn: 276973

show more ...

Implement filtering for code completion of identifiers.

Patch by Cristina Cristescu and Axel Naumann!

Agreed on post commit review (D17820).

llvm-svn: 276878

Revert r276856 "Adjust Registry interface to not require plugins to export a registry"

This is causing a huge pile of buildbot failures.

llvm-svn: 276857

Adjust Registry interface to not require plugins to export a registry

Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BU

Adjust Registry interface to not require plugins to export a registry

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

llvm-svn: 276856

show more ...

[NFC] Header cleanup

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

Patch by: Eugene <claprix@yandex.ru>

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

[NFC] Header cleanup

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

Patch by: Eugene <claprix@yandex.ru>

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

llvm-svn: 275882

show more ...

Apply clang-tidy's misc-move-constructor-init throughout Clang.

No functionality change intended, maybe a tiny performance improvement.

llvm-svn: 270996

AnnotateFunctions: Tweak for mingw.

- Externalize the registry.
- Update libdeps.

llvm-svn: 265301

[modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a single
option. Previously these options could both be used to specify that you were
compiling the implementation file of a modu

[modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a single
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.

llvm-svn: 261372

show more ...

Sink some PTHManager includes out of Preprocessor.h

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

llvm-svn: 251810

Roll-back r250822.

Summary: It breaks the build for the ASTMatchers

Subscribers: klimek, cfe-commits

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

llvm-svn: 250827

Apply modernize-use-default to clang.

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

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

D

Apply modernize-use-default to clang.

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

llvm-svn: 250822

show more ...

Replace double negation of !FileID.isInvalid() with FileID.isValid().
+couple more of double-negated !SourceLocation.isInvalid() unfixed in r249228.

llvm-svn: 249235

Fix typo.

llvm-svn: 248807

[CUDA] Allow parsing of host and device code simultaneously.

* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target spec

[CUDA] Allow parsing of host and device code simultaneously.

* 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

llvm-svn: 248299

show more ...

Rename the non-coding style conformant functions in namespace Builtins
to match the rest of their brethren and reformat the bits that need it.

llvm-svn: 244186

[Preprocessor] Iterating over all macros should include those from modules.

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

This isn't particu

[Preprocessor] Iterating over all macros should include those from modules.

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

llvm-svn: 240571

show more ...

[modules] If we re-enter a submodule from within itself (when submodule
visibility is enabled) or leave and re-enter it, restore the macro and module
visibility state from last time we were in that s

[modules] If we re-enter a submodule from within itself (when submodule
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.

llvm-svn: 237871

show more ...

Generalize future keyword compat diagnostics.

This, in preparation for the introduction of more new keywords in the
implementation of the C++ language, generalizes the support for future keyword
com

Generalize future keyword compat diagnostics.

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!

llvm-svn: 237332

show more ...

[modules] Rearrange preprocessor module visibility handling, no observable change intended.

llvm-svn: 237331

[modules] Remove dead code from Module for tracking macro import locations.

llvm-svn: 236376

[modules] If a module #includes a modular header that #undef's its macro, it
should not export the macro.

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

llvm-svn: 236369

[modules] Start moving the module visibility information off the Module itself.

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

[modules] Start moving the module visibility information off the Module itself.

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.

llvm-svn: 236300

show more ...

Add an assert to get information on buildbot failure.

llvm-svn: 236181

[modules] Stop trying to fake up a linear MacroDirective history.

Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definit

[modules] Stop trying to fake up a linear MacroDirective history.

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.

llvm-svn: 236176

show more ...