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

the current language doesn't have an import syntax and we can figure out a
suitable file to include.


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

This allows plugins which add AST passes to also define pragmas to do things
like only enable certain behaviour of the AST pass in files where a certain
pragma is used.

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


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

PR24667: fix quadratic runtime if textually-included modular headers define large numbers of macros.


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

While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.

(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)

If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)

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

Consider the following ObjC++ snippet:

--
@protocol PA;
@protocol PB;

@class NSArray<ObjectType>;
typedef int some_t;

id<PA> FA(NSArray<id<PB>> *h, some_t group);
--

This would hit an assertion in the parser after generating an annotation token
while trying to update the token cache:

Assertion failed: (CachedTokens[CachedLexPos-1].getLastLoc() == Tok.getAnnotationEndLoc() && "The annotation should be until the most recent cached token")
...
7 clang::Preprocessor::AnnotatePreviousCachedTokens(clang::Token const&) + 494
8 clang::Parser::TryAnnotateTypeOrScopeTokenAfterScopeSpec(bool, bool, clang::CXXScopeSpec&, bool) + 1163
9 clang::Parser::TryAnnotateTypeOrScopeToken(bool, bool) + 361
10 clang::Parser::isCXXDeclarationSpecifier(clang::Parser::TPResult, bool*) + 598
...

The cached preprocessor token in this case is:

greatergreater '>>' Loc=<testcase.mm:7:24>

while the annotation ("NSArray<id<PB>>") ends at "testcase.mm:7:25", hence the
assertion.

Properly update the CachedTokens during template parsing to contain
two greater tokens instead of a greatergreater.

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

rdar://problem/23494277

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

 * 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

visible in the module we're considering entering. Previously we assumed that if
we knew the include guard for a modular header, we'd already parsed it, but
that need not be the case if a header is present in the current module and one
of its dependencies; the result of getting this wrong was that the current
module's submodule for the header would end up empty.


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

local submodule visibility enabled; that top-level file might not actually be
the module includes buffer if use of prebuilt modules is disabled.


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

This is exercised by existing tests, and fixes a failure with -fsanitize=null.
No observable change otherwise; the code happened to do the right thing in
practice under recent versions of Clang and GCC because
MacroDirective::getDefinition happens to check whether this == null.


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

Introduce the clang pragmas "assume_nonnull begin" and "assume_nonnull
end" in which we make default assumptions about the nullability of many
unannotated pointers:

  - Single-level pointers are inferred to __nonnull
  - NSError** in a (function or method) parameter list is inferred to
    NSError * __nullable * __nullable.
  - CFErrorRef * in a (function or method) parameter list is inferred
    to CFErrorRef __nullable * __nullable.
  - Other multi-level pointers are never inferred to anything.

Implements rdar://problem/19191042.

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

append will resize the vector to the optimal size. No functional change
intended.

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

Patch by Косов Евгений!

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

If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.


Call sites were found with the ASTMatcher + some semi-automated cleanup.

memberCallExpr(
    argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
    on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
    hasArgument(0, bindTemporaryExpr(
                       hasType(recordDecl(hasNonTrivialDestructor())),
                       has(constructExpr()))),
    unless(isInTemplateInstantiation()))

No functional change intended.

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

module rather than requiring them to work it out themselves.


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

Switch PPCallbacks to take the new MacroDefinition instead of MacroDirective*, in order to preserve full information on module macro expansion.


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

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

This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.

So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.


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

Wire this up to "#pragma clang __debug macro <name>".


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

And thereby stop asserting.

In ObjC++ modes, we tentatively parse the lambda introducer twice: once
to disambiguate designators, which we also do in C++, and a second time
to disambiguate objc message expressions. During the second tentative
parse, the last cached token will be the annotation token we built in
the first parse. So use getLastLoc() to get the correct end location
for the rebuilt annotation.

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

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

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

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

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

[modules] Properly attribute macros to modules if they're in a file textually included into a file in the module.


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

[modules] Store a ModuleMacro* on an imported macro directive rather than duplicating the info within it.


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

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

This graph will be used to determine the current set of active macros. This is
foundation work for getting macro visibility correct across submodules of the
current module. No functionality change for now.


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