[analyzer] Recognize missing MPI collectives in MPI-Checker (#209263)
Fixes a false positive in the `optin.mpi.MPI-Checker` where legitimate
code was flagged with "Request 'X' has no matching nonblocking call."
Background for reviewers unfamiliar with MPI or this checker
------------------------------------------------------------
MPI (Message Passing Interface) is the standard API for communication
between processes in HPC/cluster programs (C/C++/Fortran). Many MPI
operations come in a *nonblocking* form, prefixed with "I" (for
"immediate"): e.g. `MPI_Isend`, `MPI_Iscatter`. A nonblocking call
returns immediately and hands back an `MPI_Request` handle; the caller
must later complete it with `MPI_Wait` (or `MPI_Waitall`). Forgetting to
wait, or reusing a request before waiting, are real bugs (buffer reuse
races, leaked requests).
The MPI-Checker (originally contributed as a GSoC 2016 project, and is a
domain-specific check - hence it's in "optin").
[57 lines not shown]
[HLSL] Consolidate texture tests (#209348)
Fixes #205878
This PR consolidates all the current texture tests into files that all
texture types can extend by adding new RUN lines.
This should greatly reduce the amount of effort required to implement
and review tests for new texture types.
Assisted by: Claude Opus 4.8
[lldb][bazel] Add the lldb-mcp binary to the Bazel overlay (#209498)
#143628 added the lldb-mcp tool (an MCP server multiplexer for LLDB),
built by lldb/tools/lldb-mcp/CMakeLists.txt. The Bazel overlay already
models the ProtocolMCP library and the MCP protocol-server plugin, but
not the lldb-mcp executable itself, so it is missing from the Bazel
build.
Add an lldb-mcp cc_binary modeled on the existing lldb-dap target: glob
tools/lldb-mcp/**, expand the macOS Info.plist via expand_template, and
depend on liblldb.wrapper, Host, Utility, ProtocolMCP, and the LLVM
Option/Support libraries. lldb-mcp has no Options.td, so unlike lldb-dap
no gentbl_cc_library is needed.
This properly translates into BUCk internally at Meta and then builds
with buck2, but I cannot validate the bazel build of this new target
directly.
bazel rule generation assisted with: claude
[NFC][WebAssembly] Move WebAssemblyCoalesceFeaturesAndStripAtomics
Move WebAssemblyCoalesceFeaturesAndStripAtomics to a separate file.
Having a pass implemented directly in the TargetMachine file is a bit
weird.
Reviewers: dschuff, sbc100, aheejin
Pull Request: https://github.com/llvm/llvm-project/pull/209046
[AMDGPU] Fix set_inactive known bits to intersect both operands (#201817)
SimplifyDemandedBitsForTargetNode grouped amdgcn_set_inactive with the
single-source readfirstlane/readlane/wwm, taking known bits from operand
1 only
Handle the data from the operand 2 inactive lanes as well
[WebAssembly] Port WebAssemblyReduceToAnyAllTruePass
Standard NewPM pass porting. Made a little bit annoying by the module
caching that I'm not sure helps much, but I've left it in.
Reviewers: aheejin, dschuff, sbc100
Pull Request: https://github.com/llvm/llvm-project/pull/209043
[libc][bazel] Add missing hdr/*_macros deps to test targets (#209761)
Commit b790c5cd2679 (#209449) switched several libc tests to include the
hdr/*_macros.h proxy headers and updated the CMake build accordingly,
but did not update the Bazel overlay. As a result, the Bazel libc test
targets include hdr/*_macros.h (and, via shared headers,
hdr/sys_mman_macros.h) without declaring the corresponding
//libc:hdr_*_macros dependencies, breaking the Bazel build with 'file
not found' / module layering errors.
Mirror the CMake dependency additions into the Bazel overlay so each
test target that includes an hdr macro header depends on the matching
//libc:hdr_*_macros (and //libc:types_struct_rlimit) target.
First found trying to land (#209747).
bazel changes assisted with: claude
cannot build with bazel locally so relying on CI to confirm green
Fix references to complete types in attribute references (#209537)
This is a regression from #197215.
Attributes are not REALLY in the body of a function (though the name of
said function is... awkwardly inaccurate at best), but still need to pay
attention to the completeness of their references. As a result, we
weren't marking the expression as invalid, but were also trying to
evaluate it.
This patch fixes this in 2 ways. First, we re-add the
CXXThisTypeOverride check, but except constant substitution, since that
has some additional 'this' behavior from #197215. x
Secondly, we also make the constant evaluator give up on incomplete
types when handling an L value member. This stops us from trying to
evaluate the value if it is incomplete during template instantiation,
when the type is incomplete. We don't diagnose, since it is still
potentially a constant expression, but isn't currently one.
Fixes: #199527