[clang-tidy] Fix false positive for generic lambda parameters in readability-non-const-parameter (#179051)
Fixes #177354
### Summary
The `readability-non-const-parameter` check produces false positives on
generic lambda parameters, not fully resolved by #177345.
### Problem
Generic lambdas with explicit template parameters create dependent
contexts that cannot be analyzed at parse time:
```cpp
auto lambda = []<typename T>(int *p) {
T x(*p); // No longer warns
};
```
[RFC][IR] Remove `Constant::isZeroValue`
`Constant::isZeroValue` currently behaves same as `Constant::isNullValue` for
all types except floating-point, where it additionally returns true for negative
zero (`-0.0`). However, in practice, almost all callers operate on
integer/pointer types where the two are equivalent, and the few FP-relevant
callers have no meaningful dependence on the `-0.0` behavior.
This PR removes `isZeroValue` to eliminate the confusing API surface. All
callers are changed to `isNullValue` with no test failures.
`isZeroValue` will be reintroduced in a future change with clearer semantics:
when null pointers may have non-zero bit patterns, `isZeroValue` will check for
bitwise-all-zeros, while `isNullValue` will check for the semantic null (which
may be non-zero).
[ELF,PPC64] Scope checkPPC64TLSRelax to section and simplify TLS markers
checkPPC64TLSRelax detects TLS GD/LD without TLSGD/TLSLD markers
(generated from old IBM XL) and disables TLS optimization. Previously it
set a per-file flag (ppc64DisableTLSRelax). Now scope it in the section
being scanned.
In addition, simplify the R_PPC64_TLSGD/R_PPC64_TLSLD marker handling:
the redundant `sym.setFlags(NEEDS_TLSIE)` is unnecessary as the
preceding GOT_TLSGD relocation already sets it.
[DAGCombiner] Fold trunc(build_vector(ext(x), ext(x)) -> build_vector(x,x) (#179857)
The original implementation performed the transformation when
isTruncateFree was true:
truncate(build_vector(x, x)) -> build_vector(truncate(x), truncate(x)).
In some cases, x comes from an ext, try to pre-truncate build_vectors
source operands
when the source operands of build_vectors comes from an ext.
Testcase from: https://gcc.godbolt.org/z/bbxbYK7dh
[clang][Python] Use fstrings instead of string concatenations (#173861)
This PR replaces string concatenations and the older `%` string
interpolation with fstrings. These changes were originally part of
#173845 but have been moved to a new PR.
[ELF] Add target-specific relocation scanning for PPC32 (#181517)
Implement PPC::scanSectionImpl, following the pattern established for
x86 (#178846) and PPC64 (#181496). This merges the getRelExpr and TLS
handling for SHF_ALLOC sections into the target-specific scanner,
enabling devirtualization and eliminating abstraction overhead.
- Inline relocation classification into scanSectionImpl with a switch
on relocation type, replacing the generic rs.scan() path.
- Use processR_PC/processR_PLT_PC for common PC-relative and PLT
relocations.
- Handle R_PPC_PLTREL24 inline with addend masking via processAux,
removing the EM_PPC special case from process().
- Handle TLS GD/LD/IE directly, eliminating handleTlsRelocation,
getTlsGdRelaxSkip, and adjustTlsExpr overrides. Use handleTlsIe
for TLS IE, and handleTlsGd for R_PPC_GOT_TLSGD16.
- Use R_DTPREL unconditionally for DTPREL relocations, removing
R_RELAX_TLS_LD_TO_LE_ABS (PPC32 was the only user).
- Move TLS relaxation dispatch from relocateAlloc into relocate,
[2 lines not shown]
[clang] Revisit tests for CWG2917 and CWG3005 after Core updates (#181513)
This patch revisits the status of tests for two aforementioned Core
issues.
I agree with the analysis in #170410, so no changes are made to CWG2917
test.
In case of CWG3005, Core approved the 2025-09-12 proposed resolution,
which the test was written against in the first place.
Fixes #170410
[ASan] [Windows] Fix a new test in mingw mode
The new test case added in 781719778003ca298ca57e486ab629b7f384844b
didn't work in mingw mode; defines set through `/D` only works when
using the clang-cl compiler driver, not the regular clang compiler
driver.
Switch this to use `-D`, which works with both plain clang and
clang-cl, so we don't need to use a lit macro for expanding
the right option to use.
[lldb] Add extended variable support to Get*VariableList.
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_extended_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include extended variables or not and leave comments explaining the decision.
As a consequence of producing extended variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no extended variables".
stack-info: PR: https://github.com/llvm/llvm-project/pull/181501, branch: users/bzcheeseman/stack/9
[ELF] Add target-specific relocation scanning for PPC64 (#181496)
Implement PPC64::scanSectionImpl, following the pattern established for
x86. This merges the getRelExpr and TLS handling for SHF_ALLOC sections
into the target-specific scanner, enabling devirtualization and
eliminating abstraction overhead.
- Inline relocation classification into scanSectionImpl with a switch
on relocation type, replacing the generic rs.scan() path.
- Use processR_PC/processR_PLT_PC for common PC-relative and PLT
relocations.
- Handle TLS GD, LD, and DTPREL directly, eliminating
handleTlsRelocation, getTlsGdRelaxSkip, and adjustTlsExpr overrides.
Use handleTlsIe for TLS IE, enabling IE-to-LE optimization even when
ppc64DisableTLSRelax is set (lifted a limitation from
the workaround patch https://reviews.llvm.org/D92959).
- Use processAux for R_PPC64_PCREL_OPT. Remove the PPC64-specific
special case from process().
- Replace RE_PPC64_RELAX_GOT_PC with R_RELAX_GOT_PC, which computes
[5 lines not shown]
[LV] Add argmin test for epilogue vectorization w/o wide canonical IV.
Add additional epilogue vectorization test coverage for
https://github.com/llvm/llvm-project/pull/170223.
Also regenerate check lines for related tests.
[lldb] Add extended variable support to Get*VariableList.
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_extended_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include extended variables or not and leave comments explaining the decision.
As a consequence of producing extended variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no extended variables".
stack-info: PR: https://github.com/llvm/llvm-project/pull/181501, branch: users/bzcheeseman/stack/9
[lldb] Scaffolding for extended variable support.
This patch handles most of the scaffolding for extended variable support that isn't directly tied to functional changes. This patch will be used by one following patch that actually modifies the lldb_private::StackFrame API to allow us to fetch extended variables.
There were a couple important/interesting decisions made in this patch that should be noted:
- Any value type may be 'extended', which is why it's a mask applied over the top of another value type.
- When printing frame variables with `fr v`, default to showing extended variables.
This new value type mask makes some of the ValueType handling more interesting, but since nothing generates objects with this mask until the next patch, we can land the concept in this patch in some amount of isolation.
stack-info: PR: https://github.com/llvm/llvm-project/pull/181500, branch: users/bzcheeseman/stack/8
[lldb] NFC: Use standard comment for lldb-python.h include (#181498)
## Summary
Use the standard `// LLDB Python header must be included first.` comment
to match every other Python interface `.cpp` file in this directory, as
suggested by @JDevlieghere.
## Test plan
NFC - comment only change.
Co-authored-by: Rahul Reddy Chamala <rachamal at meta.com>
[Github][libc] Also build arm container (#181497)
Some of the libc full build tests also run on AArch64 machines. We need
to build an ARM container or otherwise the container fails to start and
we never end up running anything.
[lldb] Fix Windows linker error for MakeSBModuleSpec in lldb-server (#181494)
## Summary
Move the definition of `ScriptInterpreter::MakeSBModuleSpec` from
`ScriptInterpreter.cpp` to `ScriptedPythonInterface.cpp`.
`MakeSBModuleSpec` constructs an `SBModuleSpec`, whose symbols live in
the API library (`liblldb`). `ScriptInterpreter.cpp` is part of
`lldbInterpreter`, which is also linked into `lldb-server` — and
`lldb-server` does not link the API library. On Windows, this causes
`LNK2019: unresolved external symbol` for `SBModuleSpec`'s constructor
and destructor.
`ScriptedPythonInterface.cpp` is part of the Python plugin library,
which only links into `liblldb` where the API symbols are available. The
method retains friend access to `SBModuleSpec` since it is still a
member of `ScriptInterpreter` regardless of which `.cpp` file defines
it.
[5 lines not shown]
[lldb] Fix pid_t redefinition on Windows in ScriptInterpreterPythonInterfaces (#181493)
## Summary
Include `lldb-python.h` as the first include inside the
`LLDB_ENABLE_PYTHON` block in `ScriptInterpreterPythonInterfaces.cpp`,
matching the pattern used by every other Python interface `.cpp` file in
this directory.
On Windows, `lldb-python.h` defines `NO_PID_T` before including
`Python.h`. This prevents `PosixApi.h` (transitively included via
`lldb-private.h`) from redefining `pid_t` with a conflicting type
(`uint32_t` vs `int`).
The issue was introduced by #181334 (ScriptedSymbolLocator plugin),
which added a new header whose include chain transitively reaches
`PosixApi.h`.
Fixes Windows build failures on lldb-aarch64-windows, lldb-x86_64-win,
and lldb-remote-linux-win.
[6 lines not shown]
