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

The current ModuleDependencyCollector has a AST listener to collect
header files present in loaded modules, but this isn't enough to collect
all headers needed in the crash reproducer. One of the reasons is that
the AST writer doesn't write symbolic link header paths in the pcm modules,
this makes the listeners on the reader only able to collect the real files.

Since the module maps could contain submodules that use headers which
are symbolic links, not collecting those forbid the reproducer scripts
to regen the modules.

For instance:

usr/include/module.map:
  ...
  module pthread {
    header "pthread.h"
    export *

    module impl {
      header "pthread_impl.h"
      export *
    }
  }
  ...

usr/include/pthread/pthread_impl.h
usr/include/pthread_impl.h -> pthread/pthread_impl.h

The AST dump for the module above:

  <SUBMODULE_HEADER abbrevid=6/> blob data = 'pthread_impl.h'
  <SUBMODULE_TOPHEADER abbrevid=7/> blob data = '/<path_to_sdk>/usr/include/pthread/pthread_impl.h'

Note that we don't have "usr/include/pthread_impl.h" which is requested
by the module.map in case we want to reconstruct the module in the
reproducer. The reason the original symbolic link path isn't used is
because the headers are kept by name and requested through the
FileManager, which unique files and returns the real path only.

To fix that, add a callback to be invoked everytime a header is added
while parsing module maps and hook that up to the module dependecy
collector. This callback is only registered when generating the
reproducer.

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

rdar://problem/24499339

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

This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)).

This was commited in r263687 and reverted in 263752 due to misaligned
access.

rdar://20588929


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

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

This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)). This enables the
compiler to provide Fix-Its for deprecated declarations.

rdar://20588929


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

We only add this to __attribute__((deprecated)).

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


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

implementation units of modules rather than interface units.


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

rdar://23891898


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

Since it's provided by the compiler. This allows a system module map
file to declare a module for it.

No test change for cstd.m, since stdatomic.h doesn't function without a
relatively complete stdint.h and stddef.h, which tests using this module
don't provide.

rdar://problem/24931246

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

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

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


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

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

If the availability context is `FunctionTemplateDecl`, we should look
through it to the `FunctionDecl`.  This prevents a diagnostic in the
following case:

    class C __attribute__((unavailable));
    template <class T> void foo(C&) __attribute__((unavailable));

This adds tests for availability in templates in many other cases, but
that was the only case that failed before this patch.

I added a feature `__has_feature(attribute_availability_in_templates)`
so users can test for this.

rdar://problem/24561029

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

This reverts commit r261780.  It turns out the original code was just
fine.  An overload for ltrim which takes char was added but the Doxygen
docs haven't seemed to pick it up.

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

This fixes PR26728.

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