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

The IR builder can constant-fold null checks if the pointer operand
points to a constant. If the "is-non-null" check is folded away to
"true", don't emit the null check + branch.

Testing: check-clang, check-ubsan.

This slightly reduces the amount of null checks we emit when compiling
X86ISelLowering.cpp. Here are the numbers from patched/unpatched clangs
based on r300371.

  -------------------------------------
  | Setup          | # of null checks |
  -------------------------------------
  | unpatched, -O0 |            25251 |
  | patched, -O0   |            23925 | (-5.3%)
  -------------------------------------

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

Pointers to the start of an alloca are non-null, so we don't need to
emit runtime null checks for them.

Testing: check-clang, check-ubsan.

This significantly reduces the amount of null checks we emit when
compiling X86ISelLowering.cpp. Here are the numbers from patched /
unpatched clangs based on r300371.

  -------------------------------------
  | Setup          | # of null checks |
  -------------------------------------
  | unpatched, -O0 |            45439 |
  | patched, -O0   |            25251 | (-44.4%)
  -------------------------------------

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

Summary:
Certain implicitly generated coroutine statements, such as the calls to 'return_value()' or `return_void()` or `get_return_object_on_allocation_failure()`, cannot be built until the promise type is no longer dependent. This means they are not built until after the coroutine body statement has been transformed.

This patch fixes an issue where these statements would never be built for coroutine templates.

It also fixes a small issue where diagnostics about `get_return_object_on_allocation_failure()` were incorrectly suppressed. 

Reviewers: rsmith, majnemer, GorNishanov, aaron.ballman

Reviewed By: GorNishanov

Subscribers: cfe-commits

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

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

It sounds like MSVC is adding support for two-phase name lookup in a
future version, enabled by this flag (see bug).

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

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

Revert "Address http://bugs.llvm.org/pr30994 so that a non-friend can properly replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp."

This reverts commit r300443. Breaks compiling libc++ with modules in
some configurations.

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

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


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

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


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

Use default ref capture to simplify local lambdas, use a template to avoid std::function overhead, other cleanup

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

Also, simplify code by calling MakeNaturalAlignAddrLValue.

This is a follow-up to r300396.

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

Address http://bugs.llvm.org/pr30994 so that a non-friend can properly replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp.

The code implements Richard Smith suggestion in comment 3 of the PR.

reviewer: Vassil Vassilev

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



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

This diff registers isConstexpr matcher.

Test plan:
make check-all
check that "match varDecl(isConstexpr())" 
works in clang-query

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


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

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

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300421 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@300420 91177308-0d34-0410-b5e6-96231b3b80d8

Patch by Dave Lee.

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

available.

Original patch by Douglas Gregor with minor modifications.

This recommits r300389, which broke bots because there have been API
changes since the original patch was written.

rdar://problem/20689633

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

with disabling it as well as disabling all vsx specific features when
turning off altivec.

Fixes PR32663.

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

If expensive checks are enabled, safe mode of libstdc++ is enabled too.
In this mode the library uses more complex data that allow additional
checks, for instance, a container may keep list of iterators that points
to it. If a code crashes it can leave these complex library objects in
inconsistent state. It occurs in a few tests that check error recovery
if compiler crashes. These test hang in expensive check mode, as the
library tries to synchronize access to the iterators pointing to some
container, but corresponding mutex remains locked after the crash.

This fix marks these tests as unsupported if clang is built with
libstdc++ safe mode enabled.

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


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

This reverts commit r300389. There were mistakes in the changes I made
to CodeGen.

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

available.

Original patch by Douglas Gregor with minor modifications.

rdar://problem/20689633

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

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

The modules side of r299226, which serializes #pragma pack state,
doesn't work well.

The main purpose was to make -include and -include-pch match semantics
(the PCH side).  We also started serializing #pragma pack in PCMs, in
the hopes of making modules and non-modules builds more consistent.  But
consider:

    $ cat a.h
    $ cat b.h
    #pragma pack(push, 2)
    $ cat module.modulemap
    module M {
        module a { header "a.h" }
        module b { header "b.h" }
    }
    $ cat t.cpp
    #include "a.h"
    #pragma pack(show)

As of r299226, the #pragma pack(show) gives "2", even though we've only
included "a.h".

- With -fmodules-local-submodule-visibility, this is clearly wrong.  We
  should get the default state (8 on x86_64).

- Without -fmodules-local-submodule-visibility, this kind of matches how
  other things work (as if include-the-whole-module), but it's still
  really terrible, and it doesn't actually make modules and non-modules
  builds more consistent.

This commit disables the serialization for modules, essentially a
partial revert of r299226.

Going forward:

 1. Having this #pragma pack stuff escape is terrible design (or, more
    often, a horrible bug).  We should prioritize adding warnings (maybe
    -Werror by default?).

 2. If we eventually reintroduce this for modules, it should only apply
    to -fmodules-local-submodule-visibility, and it should be tracked on
    a per-submodule basis.

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

If a pointer is 1-byte aligned, there's no use in checking its
alignment. Somewhat surprisingly, ubsan can spend a significant amount
of time doing just that!

This loosely depends on D30283.

Testing: check-clang, check-ubsan, and a stage2 ubsan build.

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

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

This patch teaches ubsan to insert an alignment check for the 'this'
pointer at the start of each method/lambda. This allows clang to emit
significantly fewer alignment checks overall, because if 'this' is
aligned, so are its fields.

This is essentially the same thing r295515 does, but for the alignment
check instead of the null check. One difference is that we keep the
alignment checks on member expressions where the base is a DeclRefExpr.
There's an opportunity to diagnose unaligned accesses in this situation
(as pointed out by Eli, see PR32630).

Testing: check-clang, check-ubsan, and a stage2 ubsan build.

Along with the patch from D30285, this roughly halves the amount of
alignment checks we emit when compiling X86FastISel.cpp. Here are the
numbers from patched/unpatched clangs based on r298160.

  ------------------------------------------
  | Setup          | # of alignment checks |
  ------------------------------------------
  | unpatched, -O0 |                 24326 |
  | patched, -O0   |                 12717 | (-47.7%)
  ------------------------------------------

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

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

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

CodeGenFunction::EmitObjCForCollectionStmt currently emits lifetime markers for the loop variable in an inconsistent way:  lifetime.start is emitted before the loop is entered, but lifetime.end is emitted inside the loop. AddressSanitizer uses these markers to track out-of-scope accesses to local variables, and we get false positives in Obj-C foreach loops (in the 2nd iteration of the loop). This patch keeps the loop variable alive for the whole loop by extending ForScope and registering the cleanup function inside EmitAutoVarAlloca.

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



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

The config-*triple* file handling isn't tolerant of 
leading/trailing whitespace, making it not terribly 
obvious when a single extraneous tab/space/etc will 
cause the override to be ignored. This patch simply 
trims the lines to ensure that it is tolerant of 
whitespace.


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

MOVNTDQA non-temporal aligned vector loads can be correctly represented using generic builtin loads, allowing us to remove the existing x86 intrinsics.

LLVM companion patch: D31767.

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

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

Patch by Yuka Takahashi (D31591)!


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

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


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

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

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

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

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

Printing out stack traces along with UBSan diagnostics is unsupported on
Darwin. That's because it isn't possible to use the fast unwinder or the
slow unwinder.

Apparently, it's inappropriate to use the fast unwinder for UBSan
issues. I'm not exactly sure why (see the comment in ubsan_diag.cc).
Forcing use of the fast unwinder produces decent results, AFAICT.

Darwin also does not appear to have a slow unwinder suitable for use
with the sanitizers. Apparently that's because of PR20800 [1][2]. But
that bug has been fixed. I'm not sure if there is anything preventing
use of the slow unwinder now.

Currently, passing UBSAN_OPTIONS=print_stacktrace=1 does nothing on
Darwin. This isn't good, but it might be a while before we can fix the
situation, so we should at least document it.

[1] https://github.com/google/sanitizers/issues/137
"We can't use the slow unwinder on OSX now, because Clang produces
incorrect unwind info for the ASan runtime functions on OSX
(http://llvm.org/PR20800)."

[2] https://bugs.llvm.org/show_bug.cgi?id=20800
Bug 20800 - Invalid compact unwind info generated for a function without
frame pointers on OSX

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

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

CodeGenFunction::EmitObjCForCollectionStmt currently emits lifetime markers for the loop variable in an inconsistent way:  lifetime.start is emitted before the loop is entered, but lifetime.end is emitted inside the loop.  AddressSanitizer uses these markers to track out-of-scope accesses to local variables, and we get false positives in Obj-C foreach loops (in the 2nd iteration of the loop). The markers of the loop variable need to be either both inside the loop (so that we poison and unpoison the variable in each iteration), or both outside. This patch implements the "both inside" approach.

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



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