We have the `ELF\sections.test` to test --sections.

`ELF\sections.test` uses precompiled objects, it has a bug (does not test -s alias properly).
Also, we test machine specific section types in `ELF\machine-specific-section-types.test`,
so we probably do not need to test `--sections` for a MIPS object in `ELF\sections.test`.
I think it is enough to test ELF32 and ELF64 (we do not test ELF64 in this test).

`Object/readobj-shared-object.test` also tests how llvm-readobj handles
`--sections`. It is location is wrong, it is not complete, it uses precompiled binaries
and it duplicates the `ELF\sections.test` partially (it tests both ELF32 and ELF64).

We have `ELF\readelf-s-alias.test` that tests the `-s` alias for `--sections` in llvm-readobj
and `-s` as an alias for `--symbols` in llvm-readelf.
There is no need to have a separate test for such things.
The test for the `-s` alias for `--sections` can be included into the `ELF\sections.test`.
And the test for `-s` for llvm-readelf is already included into `ELF\symbols.test`.

So, this patch:
1) Removes `Object/readobj-shared-object.test`.
2) Removes `ELF\readelf-s-alias.test`
3) Rewrites the `ELF\sections.test`.
4) Removes ELF/Inputs/trivial.obj.elf-mipsel.

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

This patch wraps an external thread local storage variable inside of a
getter function and makes it have internal linkage. This allows LLVM to
be built with BUILD_SHARED_LIBS on windows with MinGW. Additionally it
allows Clang versions prior to 10 to compile current trunk for MinGW.

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

Currently if 'expect' fails and a custom msg is supplied, then lldbtest
will not print the actual command output. This makes it impossible to know
why the test actually failed. This just prints the command output even
if the msg parameter was supplied.

Summary: This patch adds a few low level functions needed to build libc memory functions.

Reviewers: sivachandra, jfb

Subscribers: mgorny, MaskRay, tschuett, libc-commits, ckennelly

Tags: #libc-project

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

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

This reverts commit 86aae782.

A test is failing on "Release" build without assertions enabled (Fedora 31 on x86_64).

This adds a conversion function from clang::Decl to CompilerDecl. It checks
that the TypeSystemClang in the CompilerDecl actually fits to the clang::Decl
AST during creation, thus preventing the creation of CompilerDecl instances with
inconsistent state.

Summary: Fix typo

Subscribers: jvesely, nhaehnle, kerbowa, llvm-commits

Tags: #llvm

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

The refactored MemRefType::get() calls all intend to clone from another
memref type, with some modifications. In fact, some calls dropped memory space
during the cloning. Migrate them to the cloning API so that nothing gets
dropped if they are not explicitly listed.

It's close to NFC but not quite, as it helps with propagating memory spaces in
some places.

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

UserExpression::GetJITModule was used to support an option in
UserExpression::Evaluate that let you hold onto the JIT Module used during
the expression evaluation. This was only actually used in one spot --
REPL::IOHandlerInputComplete. That method didn't actually take use the
JIT module it got back, so this feature was not used in practice.
This means that we can delete the support in UserExpression::Evaluate
and delete the UserExpression::GetJITModule method entirely.

These parameters are unused in these methods, and some of them only had a
LanguageType parameter to pipe to other methods that don't use it
either.

Fixes the UnboundLocalError for the local variables out, err and
exitCode when a timeout is hit.

Both begin() and data() do the same thing for the SmallString case, but
the std::string and llvm::StringRef constructors that are being called
are defined as taking a pointer and size.

Addresses Craig Topper's feedback in https://reviews.llvm.org/D73640

One of the exit criteria of computeKnownBits is whether we reach the max
recursive call depth. Before this patch we would check that the
depth is exactly equal to max depth to exit.

Depth may get bigger than max depth if it gets passed to a different
GISelKnownBits object.
This may happen when say a generic part uses a GISelKnownBits object
with some max depth, but then we hit TL.computeKnownBitsForTargetInstr
which creates a new GISelKnownBits object with a different and smaller
depth. In that situation, when we hit the max depth check for the first
time in the target specific GISelKnownBits object, depth may already
be bigger than the current max depth. Hence we would continue to compute
the known bits, until we ran through the full depth of the chain of
computation or ran out of stack space.

For instance, let say we have
GISelKnownBits Info(/*MaxDepth*/ = 10);
Info.getKnownBits(Foo)
// 9 recursive calls to computeKnownBitsImpl.
// Then we hit a target specific instruction.
// The target specific GISelKnownBits does this:
  GISelKnownBits TargetSpecificInfo(/*MaxDepth*/ = 6)
  TargetSpecificInfo.computeKnownBitsImpl() // <-- next max depth checks would
                                            // always return false.

This commit does not have any test case, none of the in-tree targets
use computeKnownBitsForTargetInstr.

This reverts commit bebb8e25.

Pushed by accident, not yet reviewed

Add fixits for messaging self in MRR or using super, as the intent is
clear, and it turns out people do that a lot more than expected.

Allow for objc_direct_members on main interfaces, it's extremely useful
for internal only classes, and proves to be quite annoying for adoption.

Add some better warnings around properties direct/non-direct clashes (it
was done for methods but properties were a miss).

Radar-Id: rdar://problem/58355212


Signed-off-by: Pierre Habouzit <phabouzit@apple.com>

For non direct methods, the codegen uses the type of the Implementation.
Because Objective-C rules allow some differences between the Declaration
and Implementation return types, when the Implementation is in this
translation unit, the type of the Implementation should be preferred to
emit the Function over the Declaration.

Radar-Id: rdar://problem/58797748


Signed-off-by: Pierre Habouzit <phabouzit@apple.com>
Differential Revision: https://reviews.llvm.org/D73208

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

For a MC_GlobalAddress reference to a dso_local external GlobalValue with a definition, emit .Lfoo$local to avoid a relocation.

-fno-pic and -fpie can infer dso_local but -fpic cannot.  In the future,
we can explore the possibility of inferring dso_local with -fpic. As the
description of D73228 says, LLVM's existing IPO optimization behaviors
(like -fno-semantic-interposition) and a previous assembly behavior give
us enough license to be aggressive here.

Reviewed By: rnk

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

A constrained function with an auto return type would have it's definition
instantiated in order to deduce the auto return type before the constraints
are checked.

Move the constraints check after the return type deduction.

Attributes are permitted on friend definitions, but we only checked for
a proper function body, not for the =default / =delete cases.

when building a defaulted comparison.

As a convenient way of asking whether `x @ y` is valid and building it,
we previouly always performed overload resolution and built an
overloaded expression, which would both end up picking a builtin
operator candidate when given a non-overloadable type. But that's not
quite right, because it can result in our finding a user-declared
operator overload, which we should never do when applying operators
non-overloadable types.

Handle this more correctly: skip overload resolution when building
`x @ y` if the operands are not overloadable. But still perform overload
resolution (considering only builtin candidates) when checking validity,
as we don't have any other good way to ask whether a binary operator
expression would be valid.

In passing, split it up into three values (no explicit functions /
explicit conversion functions only / any explicit functions) in
preparation for using that in a future change.

This patch addresses the issue found in https://bugs.llvm.org/show_bug.cgi?id=44585
where a DW_OP_deref was placed at the end of a dwarf expression, resulting in corrupt
symbols when debugging.

This is an attempt to reland with a few fixes for buildbot since I
haven't merged from master in a bit.

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

Summary: This change reflows a comment line. This change serves as a no-op test commit

Reviewers: mclow.lists, ldionne, EricWF

Subscribers: dexonsmith, christof, libcxx-commits

Tags: #libc

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

We can have geps that have a scalar base pointer, and a vector index value, which
means that the base pointer must be splatted into a vector of pointers.

This fixes crashes on arm64 GlobalISel with optimizations enabled.

This reverts commit fff6a1b0.

This was breaking a bunch of buildbots.

This allows consumer to override in a cleaner way while still prevent
them from hitting bug without knowing they run an unsupported
configuration.

Recommit after fix by Christopher Tetreault to add parens and ${} to
cmake check to work around CMake configure time "unknown arguments
specified" issue

Differential Revision: https://reviews.llvm.org/D73677
Differential Revision: https://reviews.llvm.org/D73751

Summary:
There was a bug on LLDB VSCode where there was the following behavior:

//Code

```
struct foo {
    int bar:
};
...
foo my_foo = {10};
```

Trying to auto-complete my_foo.b with my_foo.bar resulted instead with my_foo.my_foo.bar

This diff fixes this bug and adds some tests to check correct behavior.

It also fixes the same bug using the arrow operator (->) when user manually requests completions.
TODO: Fix bug where no recommended completions are automatically shown with arrow operator

{F11249959}

{F11249958}

Reviewers: wallace

Reviewed By: wallace

Subscribers: teemperor, labath, lldb-commits

Tags: #lldb

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

This patch addresses the issue found in https://bugs.llvm.org/show_bug.cgi?id=44585
where a DW_OP_deref was placed at the end of a dwarf expression, resulting in
corrupt symbols when debugging.

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

The CMakeLists.txt had a typo which meant that check-lldb-repro was
capturing twice instead of capturing and then replaying. This also
uncovered a missing import in lldb-repro.py. This patch fixes both
issues.

GetStopDescription writes to a const char* with a given length. However,
the reproducer instrumentation serialized the char pointer and length
separately.

To serialize the string, we naively look for the first null byte to
determine its length. This can lead to the method overwriting the input
buffer when the assumed string length is smaller than the actual number
of bytes written by GetStopDescription.

The real solution is to have a custom serializer that takes both
arguments into account. However, given that these are output parameters,
they don't affect replay. If the string is passed as input later, it's
is recorded as such. Therefore I've replaced the instrumentation macro
with LLDB_RECORD_DUMMY which skips the serialization.

This reverts commit 17dbc661.

A test is failing on some bots

This reverts commit b4fac782.
It broke the MSVC bot

I believe this also fixes bugs with CI 32-bit handling, which was
incorrectly skipping offsets that look like signed 32-bit values. Also
validate the offsets are dword aligned before folding.