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

Repared support for warnings -Wkeyword-macro and -Wreserved-id-macro.
The warning -Wkeyword-macro now is not issued in patterns that are used
in configuration scripts:

    #define inline

also for 'const', 'extern' and 'static'. If macro repalcement is identical
to macro name, the warning also is not issued:

    #define volatile volatile

And finally if macro replacement is also a keyword identical to the replaced
one but decorated with leading/trailing underscores:

    #define inline __inline
    #define inline __inline__
    #define inline _inline // in MSVC compatibility mode

Warning -Wreserved-id-macro is off by default, it could help catching
things like:

    #undef __cplusplus


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

Added a new preprocessor macro: __has_declspec_attribute. This can be used as a way to determine whether Clang supports a __declspec spelling for a given attribute, similar to  __has_attribute and __has_cpp_attribute.

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

Complete support for the SD-6 standing document (based off N4200) with support for __has_cpp_attribute.

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

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

#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.


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