Commit Graph

328 Commits

Author SHA1 Message Date
John Brawn 4d79ec7fe8 Reapply r276973 "Adjust Registry interface to not require plugins to export a registry"
This differs from the previous version by being more careful about template
instantiation/specialization in order to prevent errors when building with
clang -Werror. Specifically:
 * begin is not defined in the template and is instead instantiated when Head
   is. I think the warning when we don't do that is wrong (PR28815) but for now
   at least do it this way to avoid the warning.
 * Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY
   instead provide a template definition then do explicit instantiation. No
   compiler I've tried has problems with doing it the other way, but strictly
   speaking it's not permitted by the C++ standard so better safe than sorry.

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: 277806
2016-08-05 11:01:08 +00:00
John Brawn 2853269224 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
2016-07-28 17:17:22 +00:00
John Brawn 778c3c6c61 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
2016-07-28 12:48:17 +00:00
Vassil Vassilev 644ea61d2d Implement filtering for code completion of identifiers.
Patch by Cristina Cristescu and Axel Naumann!

Agreed on post commit review (D17820).

llvm-svn: 276878
2016-07-27 14:56:59 +00:00
John Brawn 3839263204 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
2016-07-27 11:41:18 +00:00
John Brawn 63aff61019 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
2016-07-27 11:18:38 +00:00
Mehdi Amini 9670f847b8 [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
2016-07-18 19:02:11 +00:00
Benjamin Kramer cfeacf56f0 Apply clang-tidy's misc-move-constructor-init throughout Clang.
No functionality change intended, maybe a tiny performance improvement.

llvm-svn: 270996
2016-05-27 14:27:13 +00:00
NAKAMURA Takumi cacd94e242 AnnotateFunctions: Tweak for mingw.
- Externalize the registry.
  - Update libdeps.

llvm-svn: 265301
2016-04-04 15:30:44 +00:00
Richard Smith 7e82e019c6 [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
2016-02-19 22:25:36 +00:00
Reid Kleckner 738d48d5fe 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
2015-11-02 17:53:55 +00:00
Angel Garcia Gomez 637d1e6694 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
2015-10-20 13:23:58 +00:00
Angel Garcia Gomez b5250d3448 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
2015-10-20 12:52:55 +00:00
Yaron Keren 8b563665c3 Replace double negation of !FileID.isInvalid() with FileID.isValid().
+couple more of double-negated !SourceLocation.isInvalid() unfixed in r249228.

llvm-svn: 249235
2015-10-03 10:46:20 +00:00
Yaron Keren 716f3a68c9 Fix typo.
llvm-svn: 248807
2015-09-29 16:51:08 +00:00
Artem Belevich b5bc923af4 [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
2015-09-22 17:23:22 +00:00
Eric Christopher 02d5d86b4e 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
2015-08-06 01:01:12 +00:00
Jordan Rose a46bfa6b83 [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
2015-06-24 19:27:02 +00:00
Richard Smith 04765ae01e [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
2015-05-21 01:20:10 +00:00
Richard Smith 31d5184dc5 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
2015-05-14 04:00:59 +00:00
Richard Smith dbbc523639 [modules] Rearrange preprocessor module visibility handling, no observable change intended.
llvm-svn: 237331
2015-05-14 02:25:44 +00:00
Richard Smith 10434f307c [modules] Remove dead code from Module for tracking macro import locations.
llvm-svn: 236376
2015-05-02 02:08:26 +00:00
Richard Smith 38477db8c4 [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
2015-05-02 00:45:56 +00:00
Richard Smith a7e2cc684f [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
2015-05-01 01:53:09 +00:00
Richard Smith f5ec2acca9 Add an assert to get information on buildbot failure.
llvm-svn: 236181
2015-04-29 23:40:48 +00:00
Richard Smith 20e883e59b [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
2015-04-29 23:20:19 +00:00
Richard Smith 1e1728536a Refactor to make MacroState ownership and lifetime clearer.
llvm-svn: 236032
2015-04-28 21:05:07 +00:00
Richard Smith 66f5ab26e3 Fix memory leak found by asan buildbot.
llvm-svn: 235957
2015-04-28 01:11:23 +00:00
Richard Smith 753e007091 [modules] Incrementally compute the list of overridden module macros based on
the active module macros at the point of definition, rather than reconstructing
it from the macro history. No functionality change intended.

llvm-svn: 235941
2015-04-27 23:21:38 +00:00
Richard Smith b8b2ed6529 [modules] Determine the set of macros exported by a submodule at the end of that submodule.
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.

llvm-svn: 235614
2015-04-23 18:18:26 +00:00
Argyrios Kyrtzidis 5c585253e5 [Modules] Fix crash in Preprocessor::getLastMacroWithSpelling().
Macro names that got undefined inside a module may not have their MacroInfo set.

llvm-svn: 231251
2015-03-04 16:03:07 +00:00
Sean Callanan 8759649013 Modified the Objective-C lexer and parser (only
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.

llvm-svn: 223855
2014-12-09 23:47:56 +00:00
Richard Smith 3c1a41ad99 [modules] Track how 'header' directives were written in module map files,
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.

llvm-svn: 223095
2014-12-02 00:08:08 +00:00
Argyrios Kyrtzidis ee301f941c [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.

llvm-svn: 220136
2014-10-18 06:23:50 +00:00
Argyrios Kyrtzidis e62d682a27 [libclang] Allow code-completion when pointing at the end-of-file.
llvm-svn: 220135
2014-10-18 06:19:36 +00:00
David Blaikie 9f0af9d862 Unique_ptrify Preprocessor::PragmaHandlersBackup
Follow up to r217656

llvm-svn: 217829
2014-09-15 21:31:42 +00:00
Craig Topper be25030137 Use unique_ptr for ScratchBuf and PragmaHandlers in the preprocessor.
llvm-svn: 217656
2014-09-12 05:19:24 +00:00
Craig Topper b8a7053055 Unique_ptrify PPCallbacks ownership.
Unique_ptr creation stil needs to be moved earlier at some of the call sites.

llvm-svn: 217474
2014-09-10 04:53:53 +00:00
David Blaikie 6d5038c19c unique_ptrify Preprocessor's TokenLexerCache
llvm-svn: 216756
2014-08-29 19:36:52 +00:00
David Blaikie 50a5f97e82 unique_ptrify SourceManager::createFileID
llvm-svn: 216715
2014-08-29 07:59:55 +00:00
David Blaikie 49cc3181a2 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.

llvm-svn: 216614
2014-08-27 20:54:45 +00:00
Rafael Espindola d87f8d76e0 Update for LLVM api change.
llvm-svn: 216585
2014-08-27 20:03:29 +00:00
Ted Kremenek eeccb30b94 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.

llvm-svn: 216550
2014-08-27 15:14:15 +00:00
David Blaikie 23430ccb04 unique_ptr-ify FileSystemStatCache::setNextStatCache
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)

llvm-svn: 215388
2014-08-11 21:29:24 +00:00
Richard Smith 73a29662b9 Simplify MacroInfo lifetime management. We don't need three different functions
to destroy one of these.

llvm-svn: 213837
2014-07-24 03:25:00 +00:00
Richard Smith ee0c4c1673 Remove unused Prev pointer from MacroInfo chain.
Remove pointless MICache: it only ever contained up to 1 object, and was only
non-empty when recovering from an error. There's no performance or memory win
from maintaining this cache.

llvm-svn: 213825
2014-07-24 01:13:23 +00:00
Craig Topper 9d5583ef0a Convert StringLiteralParser constructor to use ArrayRef instead of a pointer and count.
llvm-svn: 211763
2014-06-26 04:58:39 +00:00
Craig Topper 4b56692e30 [C++11] Use 'nullptr'.
llvm-svn: 210448
2014-06-09 02:04:02 +00:00
Craig Topper d2d442ca73 [C++11] Use 'nullptr'. Lex edition.
llvm-svn: 209083
2014-05-17 23:10:59 +00:00
Alp Toker 2d57cea256 Provide and use a safe Token::getRawIdentifier() accessor
llvm-svn: 209061
2014-05-17 04:53:25 +00:00