llvm-project/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp:921:45:
error: missing field 'Annotations' initializer [-Werror,-Wmissing-field-initializers]
       TextEdit{Main.range("virtual1"), ""}}};
                                            ^
llvm-project/clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp:926:45:
error: missing field 'Annotations' initializer [-Werror,-Wmissing-field-initializers]
       TextEdit{Main.range("virtual2"), ""}}};
                                            ^
2 errors generated.

[-Wunsafe-buffer-usage] Ignore safe array subscripts
Don't emit warnings for array subscripts on constant size arrays where the index is constant and within bounds.

Example:
int arr[10];
arr[5] = 0; //safe, no warning

This patch recognizes only array indices that are integer literals - it doesn't understand more complex expressions (arithmetic on constants, etc.).

-Warray-bounds implemented in Sema::CheckArrayAccess() already solves a similar
(opposite) problem, handles complex expressions and is battle-tested.

Adding -Wunsafe-buffer-usage diagnostics to Sema is a non-starter as we need to emit
both the warnings and fixits and the performance impact of the fixit machine is
unacceptable for Sema.

CheckArrayAccess() as is doesn't distinguish between "safe" and "unknown" array
accesses. It also mixes the analysis that decides if an index is out of bounds
with crafting the diagnostics.

A refactor of CheckArrayAccess() might serve both the original purpose
and help us avoid false-positive with -Wunsafe-buffer-usage on constant
size arrrays.

Currently we ignore calls on function pointers (unlike direct calls of
functions and class methods). This patch adds support for function pointers as
well.

The change is to simply replace use of forEachArgumentWithParam matcher in UPC
gadget with forEachArgumentWithParamType.

from the documentation of forEachArgumentWithParamType:
/// Matches all arguments and their respective types for a \c CallExpr or
/// \c CXXConstructExpr. It is very similar to \c forEachArgumentWithParam but
/// it works on calls through function pointers as well.

Currently the matcher also uses hasPointerType() which checks that the
canonical type of an argument is pointer and won't match on arrays decayed to
pointer. Replacing hasPointerType() with isAnyPointerType() which allows
implicit casts allows for the arrays to be matched as well and this way we get
fixits for array arguments to function pointer calls too.

One of the whitespace fixes didn't get added to the commit introducing
the Ampere1B model.
Clean it up.

i386 has a `__tls_get_addr` link error.
For internal_symbolizer, the x86_64 test would fail as well.

compiler-rt was creating the test-depends targets and trying to fill its
dependencies with a variable, but the variable was empty because it was
supposed to take its value from a property. The changes in this commit
grab the value of the property and add them as dependencies.

The changes in llvm are to remove the usage of `DEPENDS` arguments from
`add_custom_target`, which according to the documentation is reserved
for files/outputs created by `add_custom_command`. Use
`add_dependencies` instead.

This is similar to the changes introduced in
4eb84582 for runtimes.

Added a test that relies on -fbasic-block-sections=all and --gc-sections
that exercises a code path that previously printed a warning.

This PR makes the checker not emit warning when a function is called
with a return value of another function when the return value is of type
Ref<T> or RefPtr<T>.

Added checkedDowncast, uncheckedDowncast, & toString as safe functions
to call in alpha.webkit.UncountedCallArgsChecker.

This PR makes alpha.webkit.UncountedCallArgsChecker eplicitly check the
safety of the object argument in a member function call. It also removes
the exemption of local variables from this checker so that each local
variable's safety is checked if it's used in a function call instead of
relying on the local variable checker to find those since local variable
checker currently has exemption for "for" and "if" statements.

This defines the builtin macros specified in `7.18a.3 Precision macros`
of ISO/IEC TR 18037:2008. These are the `__*__` versions of them and the
formal definitions in stdfix.h can use them.

Switching to modern `unittest` in
5b386158 needs xfail annotations to be
known prior to test running. In contrast, skipping can happen at any
time, even during test execution.

Thus, `expectedFailureIfFn` inherently doesn't work. Either we eagerly
evaluate the function and use `expectedFailureIf` instead, or we use a
skip annotation to lazily evaluate the function and potentially skip the
test right before it starts.

- For `expectedFailureAndroid`, the intent seems to be that certain
tests _should_ work on android, but don't. Thus, xfail is appropriate,
to ensure the test is re-enabled once those bugs are ever fixed.
- For the other uses in individual tests, those generally seem to be
cases where the test environment doesn't support the setup required by
the test, and so it isn't meaningful to run the test at all. For those,
a drop-in replacement to `skipTestIfFn` works.

Adds a comment to indicate intention of a piece of value printing code.

I was initially surprised to see this code (distilled for emphasis):

```cpp
if (str.empty()) {
  if (style == eValueObjectRepresentationStyleValue)
    str = GetSummaryAsCString();
  else if (style == eValueObjectRepresentationStyleSummary)
    str = GetValueAsCString();
}
```

My first thought was "is this a bug?", but I realized it was likely intentional. This 
change adds a comment to indicate yes, this is intentional.

On arm64 machines, when there is a hardware breakpoint or watchpoint
set, and lldb has instruction-stepped a thread, and then done a
Process::Resume, we will sometimes receive an extra "instruction step
completed" mach exception and the pc has not advanced. From a user's
perspective, they hit Continue and lldb stops again at the same spot.
From the testsuite's perspective, this has been a constant source of
testsuite failures for any test using hardware watchpoints and
breakpoints, the arm64 CI bots seem especially good at hitting this
issue.

Jim and I have been slowly looking at this for a few months now, and
finally I decided to try to detect this situation in lldb and silently
resume the process again when it happens.

We were already detecting this "got an insn-step finished mach exception
but this thread was not instruction stepping" combination in
StopInfoMachException where we take the mach exception and create a
StopInfo object for it. We had a lot of logging we used to understand
the failure as it was hit on the bots in assert builds.

This patch adds a new case to `Thread::GetPrivateStopInfo()` to call the
StopInfo's (new) `IsContinueInterrupted()` method. In
StopInfoMachException, where we previously had logging for assert
builds, I now note it in an ivar, and when
`Thread::GetPrivateStopInfo()` asks if this has happened, we check all
of the combination of events that this comes up: We have a hardware
breakpoint or watchpoint, we were not instruction stepping this thread
but got an insn-step mach exception, the pc is the same as the previous
stop's pc. And in that case, `Thread::GetPrivateStopInfo()` returns no
StopInfo -- indicating that this thread would like to resume execution.

The `Thread` object has two StackFrameLists, `m_curr_frames_sp` and
`m_prev_frames_sp`. When a thread resumes execution, we move
`m_curr_frames_sp` in to `m_prev_frames_sp` and when it stops executing,
w euse `m_prev_frames_sp` to seed the new `m_curr_frames_sp` if most of
the stack is the same as before.

In this same location, I now save the Thread's RegisterContext::GetPC
into an ivar, `m_prev_framezero_pc`. StopInfoMachException needs this
information to check all of the conditions I outlined above for
`IsContinueInterrupted`.

This has passed exhaustive testing and we do not have any testsuite
failures for hardware watchpoints and breakpoints due to this kernel bug
with the patch in place. In focusing on these tests for thousands of
runs, I have found two other uncommon race conditions for the
TestConcurrent* tests on arm64. TestConcurrentManyBreakpoints.py (which
uses no hardware watchpoint/breakpoints) will sometimes only have 99
breakpoints when it expects 100, and any of the concurrent tests using
the shared harness (I've seen it in
TestConcurrentWatchBreakDelay.py,
TestConcurrentTwoBreakpointsOneSignal.py,
TestConcurrentSignalDelayWatch.py) can fail when the test harness checks
that there is only one thread still running at the end, and it finds two
-- one of them under pthread_exit / pthread_terminate. Both of these
failures happen on github main without my changes, and with my changes -
they are unrelated race conditions in these tests, and I'm sure I'll be
looking into them at some point if they hit the CI bots with frequency.
On my computer, these are in the 0.3-0.5% of the time class. But the CI
bots do have different timing.

When parsing the `la` macro, we add a duplicate `$` prefix in
`getOrCreateSymbol`,
leading to `error: Undefined temporary symbol $$yy` for code like:

```
xx:
	la	$2,$yy
$yy:
	nop
```

Remove the duplicate prefix.

In addition, recognize `.L`-prefixed symbols as local for O32.

See: #65020.

---------

Co-authored-by: Fangrui Song <i@maskray.me>

Based on the discussion in
https://github.com/llvm/llvm-project/pull/80229
changed implementation to align with how .debug_abbrev is handled. So
that
.debug_names abbrev tag is a monotonically increasing index. This allows
for
tools like LLDB to access it in constant time using array like data
structure.

clang-19 debug build
before change

[41] .debug_names PROGBITS 0000000000000000 8f9e0350 137fdbe0 00 0 0 4
after change
[41] .debug_names PROGBITS 0000000000000000 8f9e0350 125bfdec 00 0 0 4

Reduction ~19.1MB

When applying the recommended fix for the
"modernize-use-override" clang-tidy diagnostic
there was a stray whitespace. This PR fixes that.
Resolves https://github.com/clangd/clangd/issues/1704

This reverts commit b4c7152e.

Downstream regression due to another issue that this PR exposes. We have identified the work-items to fix the new issue here: https://github.com/openxla/iree/issues/16406



Co-authored-by: Han-Chung Wang <hanchung@google.com>

Updated the check to ignore point static data members with in class
initializer since removing the inline specifier would generate a
compilation error

Fixes #80684

Add missing error check. This resolves "error: variable 'Err' set but
not used" warnings

GCC can generate rangelists/loclists that are out of order. Fixed so
that we don't assert, and instead generate partially optimized list.
Through most code paths we do sort rnglists/loclists, but not for
loclist for a path where BOLT does not modify a function. Although it's
nice to have lists sorted, this implementation shouldn't rely on it.
This also fixes an issue if we partially capture a list we would write
out *end_of_list in helper function. So tools won't see the rest of the
addresses being written out.

vector extension from v4i1 to v4i8 generates an incorrect word. This
patch uses a vtrunehb for truncation to fix the bug.

Some types of machine function and machine basic block are unsafe to
split on AArch64: basic blocks that contain jump table dispatch or
targets (D157124), and blocks that contain inline ASM GOTO blocks
or their targets (D158647) all cause issues and have been excluded
from Machine Function Splitting on AArch64.

These issues are caused by any transformation pass that places
same-function basic blocks in different text sections
(MachineFunctionSplitter and BasicBlockSections) and must be
special-cased in both passes.

The standalone runtime (not
-fsanitize-minimal-runtime/-fsanitize-trap=undefined) installs some
signal handlers using `real_sigaction`. With static linking
(-static/-static-pie), the called `REAL(sigaction)` is null, leading to
an immediate segfault, which is confusing (#51538).

Fix #51538 by bailing out.

`// REQUIRES: librt_has_multf3` from https://reviews.llvm.org/D109709
actually disabled the test because `librt_has_*` features are only for
`compiler-rt/test/builtins`. The test does not reproduce for me:
libclang_rt.builtins.a or libgcc. Revert the REQUIRES.

We recently implemented a new option allowing relinking of bitcode
modules via the "-mllvm -relink-builtin-bitcode-postop"
option.

This implementation relied on llvm::CloneModule() in order to pass
copies to modules and preserve the original modules for later relinking.
However, cloning modules has been found to be prohibitively expensive,
significantly increasing compilation time for large bitcode libraries.

In this patch, we shift the relink option implementation to instead link
the original modules initially, and reload modules from the file system
if relinking is requested. This approach results in significantly
reduced overhead.

We accomplish this by creating a new ReloadModules() routine that can be
called from a BackendConsumer class, to mimic the behavior of
ASTConsumer's loadLinkModules(), but without access to the
CompilerInstance.

Because loading the bitcodes from the filesystem requires access to the
FileManager class, we also forward a reference to the CompilerInstance
class to the BackendConsumer. This mirrors what is already done for
several CompilerInstance members, such as TargetOptions and
CodeGenOptions.

Finally, we needed to add a const specifier to the
FileManager::getBufferForFile() routine to allow it to be called using
the const reference returned from CompilerInstance::getFileManager()

I was refactoring something else but ran into this function. It was
somewhat confusing to read through and understand, but it boils down to
two steps:
- First we try `OptionArgParser::ToBoolean`. If that works, then we're
good to go.
- Second, we try `llvm::to_integer` to see if it's an integer. If it
parses to 0 or 1, we're good.
- Failing either of the steps above means we cannot parse it into a
bool.

Instead of having an integer out param and a bool return value, the
interface is better served with an optional<bool> -- Either it parses
into true or false, or you get back nothing (nullopt).

If we have a long chain of vslide1down instructions to build e.g. a <16
x i8> from scalar, we end up with a critical path going through the
entire chain. We can instead build two halves, and then combine them
with a vselect. This costs one additional temporary register, but
reduces the critical path by roughly half.

To avoid needing to change VL, we fill each half with undefs for the
elements which will come from the other half. The vselect will at worst
become a vmerge, but is often folded back into the final instruction of
the sequence building the lower half.

A couple notes on the heuristic here:
* This is restricted to LMUL1 to avoid quadratic costing reasoning.
* This only splits once. In future work, we can explore recursive
splitting here, but I'm a bit worried about register pressure and thus
decided to be conservative. It also happens to be "enough" at the
default zvl of 128.
* "8" is picked somewhat arbitrarily as being "long". In practice, our
build_vector codegen for 2 defined elements in a VL=4 vector appears to
need some work. 4 defined elements in a VL=8 vector seems to generally
produce reasonable results.
* Halves may not be an optimal split point. I went down the rabit hole
of trying to find the optimal one, and decided it wasn't worth the
effort to start with.

---------

Co-authored-by: Luke Lau <luke_lau@icloud.com>