llvm-svn: 339460

Lambdas can affect static locals even without an explicit capture.

rdar://39537031

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

llvm-svn: 339459

llvm-svn: 339458

Each test needs to be marked with the add_test_categories decorator individually.

llvm-svn: 339457

Patch by Aaron Puchert

llvm-svn: 339456

Clarify that you should not introduce trailing whitespace when making a commit and that you should not remove trailing whitespace that's unrelated to code you are changing or are about to change. Then clarified the developer policy around what is considered an obvious whitespace commit.

llvm-svn: 339455

client if the client supports this extension

This commit extends the 'textDocument/publishDiagnostics' notification sent from
Clangd to the client.  When it's enabled, Clangd sends out the fixits associated
with the appropriate diagnostic in the body of the 'publishDiagnostics'
notification. The client can enable this extension by setting 'clangdFixSupport'
to true in the textDocument capabilities during initialization.

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

llvm-svn: 339454

This includes a test that would have exposed the bug in rL339439
which was reverted at rL339446. The compare can be integer while
the binop is FP or vice-versa, so we need to use the binop type
when we ask for the identity constant.

llvm-svn: 339453

passes on 32-bit targets.

llvm-svn: 339452

<charconv> was added in r338479. Previous libcxx versions don't have
this functionality and corresponding tests should be failing.

Reviewers: mclow.lists, ldionne, EricWF

Reviewed By: ldionne

Subscribers: christof, dexonsmith, lichray, EricWF, cfe-commits

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

llvm-svn: 339451

The mangled names were added in the original commit, but
the demangled equivalents weren't, so nothing was actually
being checked.

llvm-svn: 339450

HWASan will not run on older Android releases where we use
__android_log_write for logging.

This dependency is also harmful in the case when libc itself depends
on hwasan, because it creates a loop of
  libc -> hwasan -> liblog -> libc
which makes liblog vs libc initialization order undetermined.

Without liblog the loop is just
  libc -> hwasan -> libc
and any init order issues can be solved in hwasan.

llvm-svn: 339449

llvm-svn: 339448

Summary: Similar to asan's flag, it can be used to disable the use of ifunc to access hwasan shadow address.

Reviewers: vitalybuka, kcc

Subscribers: srhines, hiraditya, llvm-commits

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

llvm-svn: 339447

That was supposed to be NFC, but it exposed a logic hole somewhere that
caused bots to fail.

llvm-svn: 339446

llvm-svn: 339441

RichManglingContext: Make m_ipd_str_len a local variable and simplify processIPDStrResult + polishing in test and Mangled

llvm-svn: 339440

This should make it easier to folow and to add the planned enhancements
such as D50190.

llvm-svn: 339439

Clang generates copy and dispose helper functions for each block literal
on the stack. Often these functions are equivalent for different blocks.
This commit makes changes to merge equivalent copy and dispose helper
functions and reduce code size.

To enable merging equivalent copy/dispose functions, the captured object
infomation is encoded into the helper function name. This allows IRGen
to check whether an equivalent helper function has already been emitted
and reuse the function instead of generating a new helper function
whenever a block is defined. In addition, the helper functions are
marked as linkonce_odr to enable merging helper functions that have the
same name across translation units and marked as unnamed_addr to enable
the linker's deduplication pass to merge functions that have different
names but the same content.

rdar://problem/42640608

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

llvm-svn: 339438

Summary:
Currently, there is two configured prefixes: `CHECK-FIXES` and `CHECK-MESSAGES`
`CHECK-MESSAGES` checks that there are no test output lines with `warning:|error:`, which are not explicitly handled in lit tests.
However there does not seem to be a nice way to enforce for all the `note:` to be checked.
This was useful for me when developing D36836.

Reviewers: alexfh, klimek, aaron.ballman, hokein

Reviewed By: alexfh, aaron.ballman

Subscribers: JonasToth, JDevlieghere, xazax.hun, cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 339437

These were completely broken before.  We need to handle
the 'B' operator tag.

llvm-svn: 339436

The check lines are marked FIXME but not the mangled names.
This is causing an error.

llvm-svn: 339435

These were uncovered when porting the mangling tests in
ms-templates.cpp from clang/CodeGenCXX over to demangling
tests.  The main issues fixed here are surrounding integer
literal signed and unsignedness, empty array dimensions,
and pointer and reference non-type template parameters.

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

llvm-svn: 339434

Fixes https://bugs.llvm.org/show_bug.cgi?id=28406

Patch by IdrissRio.

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

llvm-svn: 339433

    
Enabling ARMCodeGenPrepare by default caused a whole load of
failures. This is due to zexts and truncs not being handled properly.
ZExts are messy so it's just easier to disable for now and truncs
are allowed only as 'sinks'. I still need to figure out why allowing
them as 'sources' causes so many failures. The other main changes are
that we are explicit in the types that we converting to, it's now
always 'TypeSize'. Type support is also now performed while checking
for valid opcodes as it unnecessarily complicated having the checks
are different stages.
    
I've moved the tests around too, so we have the zext and truncs in
their own file as well as the overflowing opcode tests.

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

llvm-svn: 339432

Summary:
The current code enables aligned allocation functions when compiling in C++17
and later. This is a problem because aligned allocation functions might not
be supported on the target platform, which leads to an error at link time.

Since r338934, Clang knows not to define __cpp_aligned_new when it's not
available on the target platform -- this commit takes advantage of that to
only use aligned allocation functions when they are available.

Reviewers: vsapsai, EricWF

Subscribers: christof, dexonsmith, cfe-commits, EricWF, mclow.lists

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

llvm-svn: 339431

llvm-svn: 339430

Done as a separate commit to make it easier to cherry pick the changes
to the release branch.

llvm-svn: 339429

Summary:
Introduces funclet-based unwinding for Objective-C and fixes an issue
where global blocks can't have their isa pointers initialised on
Windows.

After discussion with Dustin, this changes the name mangling of
Objective-C types to prevent a C++ catch statement of type struct X*
from catching an Objective-C object of type X*.

Reviewers: rjmccall, DHowett-MSFT

Reviewed By: rjmccall, DHowett-MSFT

Subscribers: mgrang, mstorsjo, smeenai, cfe-commits

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

llvm-svn: 339428

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

llvm-svn: 339427

This patch modifies `consume` function to allow retrieval of limited
number of symbols. This is the "cheap" implementation of top-level
limiting iterator. In the future we would like to have a complete limit
iterator implementation to insert it into the query subtrees, but in the
meantime this version would be enough for a fully-functional
proof-of-concept Dex implementation.

Reviewers: ioeric, ilya-biryukov

Reviewed by: ioeric

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

llvm-svn: 339426

llvm-svn: 339425

llvm-svn: 339424

This patch fixes a wrong type bug inside ParsedAttr::TypeTagForDatatypeData.
The details to the best of my knowledge are as follow. The incredible thing
is that everything works out just fine by chance due to a sequence of lucky
coincidences in the layout of various types.

The struct ParsedAttr::TypeTagForDatatypeData contains among other things
a ParsedType *MatchingCType, where ParsedType is just OpaquePtr<QualType>.

However the member MatchingCType is initialized in the constructor for
type_tag_for_datatype attribute as follows:

new (&ExtraData.MatchingCType) ParsedType(matchingCType);

This results in the ParsedType being constructed in the location of the
ParsedType * Later ParsedAttr::getMatchingCType do return
*getTypeTagForDatatypeDataSlot().MatchingCType; which instead of
dereferencing the ParsedType * will dereference the QualType inside
the ParsedType. Now this QualType in this case contains no qualifiers
and therefore is a valid Type *. Therefore getMatchingCType returns a
Type or at least the stuff that is in the first sizeof(void*) bytes of it,
But it turns out that Type inherits from ExtQualsCommonBase and that the
first member of ExtQualsCommonBase is a const Type *const BaseType. This
Type * in this case points to the original Type pointed to by the
QualType and so everything works fine even though all the types were wrong.

This bug was only found because I changed the layout of Type,
which obviously broke all of this long chain of improbable events.

Reviewed By: erichkeane

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

llvm-svn: 339423

llvm-svn: 339422

Part of the logic has been moved to helper functions to (hopefully) improve
readability.
Added a few code comments to better describe how the algorithm works.

No functional change intended.

llvm-svn: 339421

This extension emits the guard cf table without inserting the
instrumentation. Currently that's what clang-cl does with /guard:cf
anyway, but this allows a user to request that explicitly.

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

llvm-svn: 339420

The previous name sounds like it inserts cfguard implementation, but it
really just emits the table of address-taken functions. Change the name
to better reflect that.

Clang will be updated in the next commit.

llvm-svn: 339419

llvm-svn: 339417

llvm-svn: 339416