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

file in the loaded module maps and one of them is from the current module,
that's the right match.


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

Update for LLVM API change to return by InputArgList directly (rather than by pointer) from ParseArgs

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

As specified in the SysV AVX512 ABI drafts. It follows the same scheme
as AVX2: 

    Arguments of type __m512 are split into eight eightbyte chunks.
    The least significant one belongs to class SSE and all the others
    to class SSEUP.

This also means we change the OpenMP SIMD default alignment on AVX512.

Based on r240337.
Differential Revision: http://reviews.llvm.org/D9894


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

Follow-up to r237989: expressing the AVX level as an enum makes it
simple to extend it with AVX512.


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

[modules] Add a flag to disable the feature that permits conflicting redefinitions of internal-linkage symbols that are not visible.

Such conflicts are an accident waiting to happen, and this feature conflicts
with the desire to include existing headers into multiple modules and merge the
results. (In an ideal world, it should not be possible to export internal
linkage symbols from a module, but sadly the glibc and libstdc++ headers
provide 'static inline' functions in a few cases.)


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

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

The asan/not_asan and ubsan/not_ubsan features weren't being set
correctly when LLVM_USE_SANITIZER is set to 'Address;Undefined'. Fix
this by doing substring instead of exact matching. Also simplify the
msan check for consistency.

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

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

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

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

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

The patch is generated using this command:

  $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
      -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
      work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.



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

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

The same pattern was repeated a few times.  Create a trivial helper method to
map the Type Specifier to an ID for the diagnostic.  Flip the selection order on
one of the diagnostic messages to get the same ordering across all of the
messages.  This makes the emission of the diagnostic slightly more legible by
changing the cascading ternary into a switch in a function.  NFC.

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

Move /Qvec flags from the "// Non-aliases:" section up to the "// Aliases:"
section since the flags are just aliases.  For the same reason, move the
/vm flags the other way.  Also reflow a few lines to 80 columns.

No behavior change.


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

This is a better approach to fixing the undefined behaviour I tried to
fix in r240228. This data doesn't necessarily have suitable alignment
for uint64_t, so use unaligned_uint64_t instead.

This fixes 225 test failures when clang is built with ubsan.

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

We can do this better by changing the type to unaligned_uint64_t and
paying the cost on use instead of up front.

This reverts r240228

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

Convert a hand rolled for loop into an explicit for loop.  NFC.

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

Testcase provided, in the PR, by Christian Shelton and
reduced by David Majnemer.

PR:		23584
Differential Revision:	http://reviews.llvm.org/D10508
Reviewed by:	rnk


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

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

We interpret Blob as an array of uint64_t here, but there's no reason
to think that it has suitable alignment. Instead, read the data in in
an alignment-safe way and store it in a std::vector.

This fixes 225 test failures when clang is built with ubsan.

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

A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.

The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.

rdar://problem/20091852

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

We already test for PrioritizedCXXGlobalInits being non-empty
and process it so it makes sense to clear it only in that if.



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

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

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

[modules] When determining whether a definition of a class is visible, check all modules even if we've already found a definition that's not visible.


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

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

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

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

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

These usually apply to the return type. At one point this was necessary to
get some of them to apply to the entire block, but it appears that's working
anyway (see block-return.c).

rdar://problem/20468034

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

...instead of as a special case in ParseObjCTypeName with lots of
duplicated logic. Besides being a nice refactoring, this also allows
"- (instancetype __nonnull)self" in addition to "- (nonnull instancetype)self".

rdar://problem/19924646

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

rdar://problem/21134250

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

That is,

  void cf2(CFTypeRef * __nullable p CF_RETURNS_NOT_RETAINED);

is equivalent to

  void cf2(CFTypeRef __nullable * __nullable p CF_RETURNS_NOT_RETAINED);

More rdar://problem/18742441

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

Includes a simple static analyzer check and not much else, but we'll also
be able to take advantage of this in Swift.

This feature can be tested for using __has_feature(cf_returns_on_parameters).

This commit also contains two fixes:
- Look through non-typedef sugar when deciding whether something is a CF type.
- When (cf|ns)_returns(_not)?_retained is applied to invalid properties,
  refer to "property" instead of "method" in the error message.

rdar://problem/18742441

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

Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support and are
not toolchain- or architecture-dependent.

Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.

This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539).

Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.

This change was first submitted as r239953 and reverted in r239958.
The problem was and still is in Darwin toolchains, which get the
knowledge about target platform too late after initializaition, while
now we require this information when ToolChain::getSanitizerArgs() is
called. r240170 works around this issue.

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

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

Summary:
This is unfortunate, but would let us land http://reviews.llvm.org/D10467,
that makes ToolChains responsible for computing the set of sanitizers
they support.

Unfortunately, Darwin ToolChains doesn't know about actual OS they
target until ToolChain::TranslateArgs() is called. In particular, it
means we won't be able to construct SanitizerArgs for these ToolChains
before that.

This change removes SanitizerArgs::needsLTO() method, so that now
ToolChain::IsUsingLTO(), which is called very early, doesn't need
SanitizerArgs to implement this method.

Docs and test cases are updated accordingly. See
https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we
start all these.

Test Plan: regression test suite

Reviewers: pcc

Subscribers: cfe-commits

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

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

Another part of rdar://problem/18868820.

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