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 '#pragma once' directive was erroneously ignored when encountered
in the header-file specified in generate-PCH-mode. This resulted in
compile-time errors in some cases with legal code, and also a misleading
warning being produced.

Patch by Warren Ristow!

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


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

SM.isWrittenInSameFile() calls getFileID(), which can be expensive.
Move this check behind some cheaper filters.

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

This patch adds a __nth_element builtin that allows fetching the n-th type of a
parameter pack with very little compile-time overhead. The patch was inspired by
r252036 and r252115 by David Majnemer, which add a similar __make_integer_seq
builtin for efficiently creating a std::integer_sequence.

Reviewed as D15421. http://reviews.llvm.org/D15421



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

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

Patch for r272584 (http://reviews.llvm.org/rL272584) to address clang-x64-ninja-win7 buildbot failure.

Patch by Eric Niebler



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

Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842

Re-commit of r272562 after addressing clang-x86-win2008-selfhost failure.



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

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

Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842

Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures.

Patch by Eric Niebler



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

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

Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842

Patch by Eric Niebler



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

This reverts commit r270580.  Using __has_feature to test for
type-traits is deprecated.

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

It looks like we forgot to update the __has_feature support when we
added some of the type traits.

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

MSVC now supports the __is_assignable type trait intrinsic,
to enable easier and more efficient implementation of the
Standard Library's is_assignable trait.
As of Visual Studio 2015 Update 3, the VC Standard Library
implementation uses the new intrinsic unconditionally.

The implementation is pretty straightforward due to the previously
existing is_nothrow_assignable and is_trivially_assignable.
We handle __is_assignable via the same code as the other two except
that we skip the extra checks for nothrow or triviality.

Patch by Dave Bartolomeo!

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

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

The lexer sets the end location of macro arguments incorrectly *if*,
while merging consecutive args to fit into a single SLocEntry, it finds
args which come from different macro files.

Fix the issue by using separate SLocEntries in this situation.

This fixes a code coverage crasher (rdar://problem/26181005). Because
the lexer reported end locations for certain macro args incorrectly, we
would generate bogus coverage mappings with negative line offsets.

Reviewed-by: akyrtzi

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

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

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

If we are processing a #include from a module build, we should treat it
as a system header if we're building a system module. Passing an optional
flag to HeaderSearch::LookupFile.

Before this, the testing case will crash when accessing a freed FileEntry.

rdar://26214027


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

getModuleContainingLocation ends up on the hot-path for typical C code
which can lead to calls to getFileIDSlow.

To speed this up, short circuit inferModuleFromLocation when there
aren't any modules, implicit or otherwise.

This shaves 4-5% build time when building the linux kernel.

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

Clang performs directory walk while searching headers inside modules by
using the ::sys::fs instead of ::vfs. This prevents any code that uses
the VFS (e.g, reproducer scripts) to actually find such headers, since
the VFS will never be searched for those.

Change these places to use vfs::recursive_directory_iterator and
vfs::directory_iterator instead.

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

rdar://problem/25880368

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

(1) Collect headers under inner frameworks (frameworks inside other
other frameworks).
(2) Make sure we also collect the right header files inside them.

More info on (2):

Consider a dummy framework module B, with header Frameworks/B/B.h. Now
consider that another framework A, with header Frameworks/A/A.h, has a
layout with a inner framework Frameworks/A/Frameworks/B/B.h, where the
"B/B.h" part is a symlink for Frameworks/B/B.h. Also assume that
Frameworks/A/A.h includes <B/B.h>.

When parsing header Frameworks/A/A.h, framework module lookup is
performed in search for B, and it happens that
"Frameworks/A/Frameworks/B/B.h" path is registered in the module instead
of real "Frameworks/B/B.h". This occurs because
"Frameworks/A/Frameworks/B/B.h" is scanned first by the FileManager,
when looking for inner framework modules under Frameworks/A/Frameworks.
This makes Frameworks/A/Frameworks/B/B.h the default cached named inside
the FileManager for the B.h file UID.

This leads to modules being built without consistent paths to underlying
header files. This is usually not a problem in regular compilation flow,
but it's an issue when running the crash reproducer. The issue is that
clangs collect "Frameworks/A/Frameworks/B/B.h" but not
"Frameworks/B/B.h" into the VFS, leading to err_mmap_umbrella_clash. So
make sure we also collect the original header.

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

rdar://problem/25880368

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

This patch corresponds to reviews:
http://reviews.llvm.org/D15120
http://reviews.llvm.org/D19125

It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.

If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.


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

Use a StringRef instead of a FileEntry in the moduleMapAddHeader
callback to allow more flexibility on what to collect on further
patches. This changes the interface I introduced in r264971.

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

Was causing warnings during the build.



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

Summary:
Adds a framework to enable the instrumentation pass for the new
EfficiencySanitizer ("esan") family of tools.  Adds a flag for esan's
cache fragmentation tool via -fsanitize=efficiency-cache-frag.
Adds appropriate tests for the new flag.

Reviewers: eugenis, vitalybuka, aizatsky, filcab

Subscribers: filcab, kubabrecka, llvm-commits, zhaoqin, kcc

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

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

xmmintrin.h a bit more directed. If for whatever reason modules are enabled but
we textually include one of these headers, don't deploy the special case for
modules. To make this work cleanly, extend __building_module to be defined
even when modules is disabled.


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

in a preprocessor constant expression.


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

Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).


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

This patch corresponds to review:
http://reviews.llvm.org/D15120

It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.

Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.


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

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

and we fall back to textual inclusion, don't require the module as a whole to
be marked available; it's OK if some other file in the same module is missing,
just as it would be if the header were explicitly marked textual.


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

Summary:
The parsing logic has been separated out from the macro implementation logic, leading to a number of improvements:

* Gracefully handle unexpected/invalid tokens, too few, too many and nested parameters
* Provide consistent behaviour between all built-in feature-like macros
* Simplify the implementation of macro logic
* Fix __is_identifier to correctly return '0' for non-identifiers

Reviewers: doug.gregor, rsmith

Subscribers: rsmith, cfe-commits

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

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

For completeness, add a test-case for the equivalent stringize operator
diagnostic too.


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

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

This can happen as we look for '<<<<' while scanning tokens but then expect
'<<<<\n' to tell apart perforce from diff3 conflict markers. Just harden
the pointer arithmetic.

Found by libfuzzer + asan!

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