This clears the way for the raw lines themselves to be parsed easily.

(Okay, one functional change: fix punctuation linebreaks with trailing WS)

Summary: (Only if their definitions are visible and they have no other docs)

Reviewers: kadircet

Subscribers: jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

The implementation of shape inference in the toy tutorial did not conform to the correct algorithmic description.
The result was only correct because all operations appear to be processed in sequence.

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

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

as invalid.

We create those when forming trivial type source information with no
associated location, which, unfortunately, we do create in some cases
(when a TreeTransform with no base location is used to transform a
QualType).

This would previously lead to rejects-valid bugs when we misinterpreted
these constructs as having no nested-name-specifier.

 Fix two typos throughout the chapters.

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

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

Mark it expected fail for now.

The test output shows that the "internal" thread listing isn't showing the
step out plan that we use to step back out of a function we're stepping into.
The internal plan listing code has nothing platform specific in it, so that
isn't the problem.

I am pretty sure the difference is that on MacOS we step into the function and then need to
step back out again so we push the internal plan the test is checking for.  But on Linux we
are able to step past the function without stepping into it.

So nothing is actually going wrong here, I just need to find a better test case where I
can ensure we are going to have to push a private plan.  It's probably better to test this
using a custom thread plan, then I can control the state of the plan stack better.

That's for Monday...

Summary:
A recent change in ThreadPlans introduced this little compilation error.
Seems to be related to the work around https://reviews.llvm.org/D76814.

Reviewers: clayborg, labath, jingham

Reviewed By: jingham

Subscribers: lldb-commits

Tags: #lldb

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

Summary: The attribute grammar includes an optional trailing colon type, so for attributes without a constant buildable type this will generally lead to unexpected and undesired behavior. Given that, it's better to just error out on these cases.

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

Summary:
In this diff of mine D77186 I introduce a bug in the replace operation, where I was failing fast by mistake.
Besides, a similar problem existed in the insert-after operation, where it was failing fast.

Finally, the remove operation was wrong, as it was not using the indices provided by the users.

I fixed those issues and added some tests account for cases with multiple elements in these requests.

Reviewers: labath, clayborg

Reviewed By: labath

Subscribers: mgrang, lldb-commits

Tags: #lldb

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

Summary: It is a very common user trap to think that the location printed along with the diagnostic is the same as the current operation that caused the error. This revision changes the behavior to always print the current operation, except for when diagnostics are being verified. This is achieved by moving the command line flags in IR/ to be options on the MLIRContext.

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

Pre-committing the new test case so the review shows only the diffs.

memchr consistent and comprehensible, and document them.

We previously allowed evaluation of memcmp on arrays of integers of any
size, so long as the call evaluated to 0, and allowed evaluation of
memchr on any array of integral type of size 1 (including enums). The
purpose of constant-evaluating these builtins is only to support
constexpr std::char_traits, so we now consistently allow them on arrays
of (possibly signed or unsigned) char only.

capture the test stdout, so put the info I need to see in the error
message instead.

In contexts where we know an LLVM type is a pointer, there's generally
some simpler way to get the pointee type.

(See also D76269.)

(See also D76269.)

(See also D76269.)

NFC.

Summary:
@labath mentioned to me that test files shouldn't have a license header.
I saw this one some days ago, so I'm doing some cleaning.

Reviewers: labath, clayborg

Subscribers: lldb-commits, labath

Tags: #lldb

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

Also turn on the command trace unconditionally for TestThreadPlanCommands.py as the
tests for the Ubuntu bot don't seem to run with -t making it hard to see why this is
failing remotely.

This reverts commit c74dd640.

Reverting to address coding standard issues raised in post-commit
review.

This reverts commit 62c42e29

Reverting to address coding standard issues raised in post-commit
review.

An enum may be considered to be a complete type if it was forward
declared. It may be declared with a fixed underlying type, or, in MSVC
compatiblity mode, with no type at all.

Previously, the code was written with special handling for fixed enums.
I generalized the code to check if the underlying integer type is known,
which should be the case when targetting the MSVC C++ ABI.

Fixes PR45409

Always depend on the compiler to have a correct implementation of
max_align_t in stddef.h and don't provide a fallback. For pre-C++11,
require __STDCPP_NEW_ALIGNMENT__ in <new> as provided by clang in all
standard modes. Adjust test cases to avoid testing or using max_align_t
in pre-C++11 mode and also to better deal with alignof(max_align_t)>16.
Document requirements of the alignment tests around natural alignment of
power-of-two-sized types.

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

When a category/extension doesn't repeat a type bound, corresponding
type parameter is substituted with `id` when used as a type argument. As
a result, in the added test case it was causing errors like

> type argument 'T' (aka 'id') does not satisfy the bound ('id<NSCopying>') of type parameter 'T'

We are already checking that type parameters should be consistent
everywhere (see `checkTypeParamListConsistency`) and update
`ObjCTypeParamDecl` to have correct underlying type. And when we use the
type parameter as a method return type or a method parameter type, it is
substituted to the bounded type. But when we use the type parameter as a
type argument, we check `ObjCTypeParamType` that wasn't updated and
remains `id`.

Fix by updating not only `ObjCTypeParamDecl` UnderlyingType but also
TypeForDecl as we use the underlying type to create a canonical type for
`ObjCTypeParamType` (see `ASTContext::getObjCTypeParamType`).

This is a different approach to fixing the issue. The previous one was
02c2ab3d which was reverted in
4c539e8d. The problem with the previous
approach was that `ObjCTypeParamType::desugar` was returning underlying
type for `ObjCTypeParamDecl` without applying any protocols stored in
`ObjCTypeParamType`. It caused inconsistencies in comparing types before
and after desugaring.

rdar://problem/54329242

Reviewed By: erik.pilkington

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

clang with -flto does not handle -foptimization-record-path=<path>

This dulicates the code from ToolChains/Clang.cpp with modifications to
support everything in the same fashion.

Summary: Switched to using the new memcpy implementation.

Reviewers: sivachandra, abrachet, gchatelet

Reviewed By: abrachet, gchatelet

Subscribers: mgorny, MaskRay, tschuett, libc-commits

Tags: #libc-project

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

Apparently the intention was to copy the condition above:
  if (types.GetSize() >= max_matches)
    break;

So that if the iteration stopped because of too many matches we do not
add even more matches in this 'Clang modules' block downward.

It was implemented by:
  SymbolFileDWARF: Unconditionally scan through clang modules. NFCish
  fe9eaadd

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

Summary: This should fix the call to a non internal libc function.

Reviewers: sivachandra, abrachet

Reviewed By: sivachandra

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

Tags: #libc-project

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

that were not reported by the OS plugin.  To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap.
Also move dumping thread plans there as well.

Added some tests for "thread plan list" and "thread plan discard" since
I didn't seem to have written any originally.

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

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

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

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

Summary:
A recent extension allowed the `loop.if` operation to return results yielded by
its regions. However, such operations could not be lowered to a CFG of standard
operations because it would have required to modify the argument list of a
block, which is not allowed in a conversion pattern. Now that the conversion
infrastructure supports block creation, use it to create a block with an
argument list that dominates the operations following the `loop.if` and forward
the results as arguments of this block.

Depends On D77416

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