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

The coverage implementation marks functions which won't be emitted as
'deferred', so that it can emit empty coverage regions for them later
(once their linkages are known).

Functions in dependent contexts are an exception: if there isn't a full
instantiation of a function, it shouldn't be marked 'deferred'. We've
been breaking that rule without much consequence because we just ended
up with useless, extra, empty coverage mappings. With PR32679, this
behavior finally caused a crash, because clang marked a partial template
specialization as 'deferred', causing the MS mangler to choke in its
delayed-template-parsing mode:

  error: cannot mangle this template type parameter type yet
  (http://bugs.llvm.org/show_bug.cgi?id=32679)

Fix this by checking if a decl's context is a dependent context before
marking it 'deferred'.

Based on a patch by Adam Folwarczny!

Differential Revision: https://reviews.llvm.org/D32144

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

rdar://problem/31635406

Differential Revision: https://reviews.llvm.org/D32187

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

This should simplify the call sites, which typically want to tweak one
attribute at a time. It should also avoid creating ephemeral
AttributeLists that live forever.

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

Prior to this commit the external_source_symbol attribute wasn't supported by
#pragma clang attribute for the following two reasons:

- The Named attribute subject hasn't been supported by TableGen.
- There was no way to specify a subject match rule for #pragma clang attribute
 that could operate on a set of attribute subjects (e.g. the ones that derive
 from NamedDecl).

This commit fixes the two issues and thus adds external_source_symbol support to
#pragma clang attribute.

rdar://31169028

Differential Revision: https://reviews.llvm.org/D32176


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

Patch by: Gergely Angeli!

Differential Revision: https://reviews.llvm.org/D31938


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

While at it, extend test for FreeBSD and check for -lrt iff on Linux.

Differential Revision: https://reviews.llvm.org/D30087

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

Under -fms-extensions __unaligned is a type-qualifier that can be applied to a
non-static member function declaration.

This causes an assertion when mangling the name under Itanium, where that
qualifier is not mangled.

This patch justs makes the minimal change to avoid the crash and avoid mangling
__unaligned, as it currently happens with non-member functions.

Differential Revision: https://reviews.llvm.org/D31976



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

This commit teaches Clang to recognize editor placeholders that are produced
when an IDE like Xcode inserts a code-completion result that includes a
placeholder. Now when the lexer sees a placeholder token, it emits an
'editor placeholder in source file' error and creates an identifier token
that represents the placeholder. The parser/sema can now recognize the
placeholders and can suppress the diagnostics related to the placeholders. This
ensures that live issues in an IDE like Xcode won't get spurious diagnostics
related to placeholders.

This commit also adds a new compiler option named '-fallow-editor-placeholders'
that silences the 'editor placeholder in source file' error. This is useful
for an IDE like Xcode as we don't want to display those errors in live issues.

rdar://31581400

Differential Revision: https://reviews.llvm.org/D32081


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

No tests yet, but this will be tested by the upcoming:
https://reviews.llvm.org/D28462

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

modules but exposes much more widespread issues. Example and more
information is on the review thread for r300650.

Original commit summary:
[modules] Properly look up the owning module for an instantiation of a merged template.

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

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

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

When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.


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

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

The driver needs to know whether it's building a module interface or
implementation unit because it affects which outputs it produces and how it
builds the command pipeline. But the frontend doesn't need to know and should
not care: all it needs to know is what action it is being asked to perform on
the input.

(This is in preparation for permitting -emit-obj to be used on a module
interface unit to produce object code without going via a "full" PCM file.)


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

Do not warn about whitespace between ??/ trigraph and newline in line comments if trigraphs are disabled in the current language.


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

Patch by Yuka Takahashi (D32119)!


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

UBSAN 'invalid value' failures

The commit r300556 introduced a UBSAN issue that was caught by
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap. The DenseMap
failed to create an empty/tombstone value as the empty/tombstone values for the
SubjectMatchRule enum were not valid enum constants.


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

- To be consistent with the rest of the intrinsics headers, I removed the tags <i> .. </i> for marking instruction names in italics in in smmintrin.h. 

- Formatting changes to fit into 80 characters. 

I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.



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

The Result variable is unused both in Sema::CheckARMBuiltinFunctionCall
and Sema::CheckAArch64BuiltinFunctionCall, remove it.

Patch by Wei-Ren Chen!

Reviewers: craig.topper, rnk

Reviewed By: rnk

Subscribers: aemerson, cfe-commits, rengolin

Differential Revision: https://reviews.llvm.org/D32014

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

Summary:
Pass Cpu/Arch options to assembler for AArch64 with no-integrated-as.
This fixes PR20019.

Reviewers: richard.barton.arm, kristof.beyls, rengolin

Reviewed By: rengolin

Subscribers: srhines, pirama, aemerson, rengolin, cfe-commits

Differential Revision: https://reviews.llvm.org/D32132

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

Summary: Test commit access.

Reviewers: gbiv, george.burgess.iv

Reviewed By: george.burgess.iv

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D32161

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

Add selectany as a GCC spelling for mingw-w64

Reviewers: rnk

Differential revision: https://reviews.llvm.org/D32083

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

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

This is a recommit of r300539 that was reverted in r300543 due to test failures.
The original commit message is displayed below:

The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.

Differential Revision: https://reviews.llvm.org/D30009


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

Stop blindly searching for "gcc.exe" on windows.
Stop assuming "/usr" on unix, fixes cross compiling.

Reviewers: mati865, yaron.keren

Subscribers: ismail, rnk

Differential revision: https://reviews.llvm.org/D15005

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

This passes an option to the ARM assembly parser to emit build
attributes for the hardware selected by command line options, when
assembling an assembly file.

This is not enabled for C/C++, as this would result in duplicate build
attribute directives being emitted in each inline assembly block, when
emitting assembly.

This also adds an option to allow disabling this behaviour for assembly
files, for users who were relying on the old behaviour.

Differential revision: https://reviews.llvm.org/D31813



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

This macro is defined for arm-none-eabi as of r266625, but it should also be
defined for eabihf and aarch64.



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

Some tests fail on the Windows buildbots. I will have to investigate more.
This commit reverts r300539, r300540 and r300542.


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

The warning was caused by r300539.


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

This should fix the Windows buildbot failure that happened after r300539.


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

The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.

Differential Revision: https://reviews.llvm.org/D30009


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

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

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

[coroutines] Fix building of new/delete expressions when get_return_object_on_allocation_failure() is present.

Summary:
This patch implements [dcl.fct.def.coroutine]p8:
> The unqualified-id get_return_object_on_allocation_failure is looked up in the scope of
> class P by class member access lookup (3.4.5). If a declaration is found, ..., and if a 
> global allocation function is selected, the ::operator new(size_t, nothrow_t) form shall be used.
> [...]
> The allocation function used in this case must have a non-throwing noexcept-specification.

Reviewers: GorNishanov, rsmith, majnemer, aaron.ballman

Reviewed By: GorNishanov

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D31562

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

LLVM has changed the semantics of dbg.declare for describing function
arguments. After this patch a dbg.declare always takes the *address*
of a variable as the first argument, even if the argument is not an
alloca.

https://bugs.llvm.org/show_bug.cgi?id=32382
rdar://problem/31205000

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

Previously, if an escaped newline was followed by a newline or a nul, we'd lex
the escaped newline as a bogus space character. This led to a bunch of
different broken corner cases:

For the pattern "\\\n\0#", we would then have a (horizontal) space whose
spelling ends in a newline, and would decide that the '#' is at the start of a
line, and incorrectly start preprocessing a directive in the middle of a
logical source line. If we were already in the middle of a directive, this
would result in our attempting to process multiple directives at the same time!
This resulted in crashes, asserts, and hangs on invalid input, as discovered by
fuzz-testing.

For the pattern "\\\n" at EOF (with an implicit following nul byte), we would
produce a bogus trailing space character with spelling "\\\n". This was mostly
harmless, but would lead to clang-format getting confused and misformatting in
rare cases. We now produce a trailing EOF token with spelling "\\\n",
consistent with our handling for other similar cases -- an escaped newline is
always part of the token containing the next character, if any.

For the pattern "\\\n\n", this was somewhat more benign, but would produce an
extraneous whitespace token to clients who care about preserving whitespace.
However, it turns out that our lexing for line comments was relying on this bug
due to an off-by-one error in its computation of the end of the comment, on the
slow path where the comment might contain escaped newlines.


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

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

I have no idea what's happening here. The tests that fail on all of the bots
pass on my machine. Further investigation needed.

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