1. Sema: extract a check for `isCFError` (NFC) (details)
  2. [HIP] Add gfx1031 and gfx1030 (details)
  3. Revert "Retry of D84974" (details)
  4. [Asan] Don't crash if metadata is not initialized (details)
  5. [NFC][Asan] Remove Debug code (details)
Commit f4ac79a364f2de7270a3238b176e17b40b036305 by Saleem Abdulrasool
Sema: extract a check for `isCFError` (NFC)

Extract a simple check to check if a `RecordDecl` is a `CFError` Decl.
This is a simple refactoring to prepare for an upcoming change.  NFC.

Patch is extracted from
The file was modifiedclang/include/clang/Sema/Sema.h (diff)
The file was modifiedclang/lib/Sema/SemaType.cpp (diff)
Commit 041da0d828e39d849c99adf1391aaa9291f4310f by Yaxun.Liu
[HIP] Add gfx1031 and gfx1030

Differential Revision:
The file was modifiedclang/lib/Basic/Cuda.cpp (diff)
The file was addedclang/test/Driver/hip-offload-arch.hip
Commit 5c463d107d3c26fc5573f31b838a8a3a1e4b5065 by walter erquinigo
Revert "Retry of D84974"

This reverts commit 5b2b4f331d78f326e5e29166bec5ad92c864343d.

This caused a link error in
The file was modifiedlldb/tools/lldb-vscode/VSCode.h (diff)
The file was modifiedlldb/packages/Python/lldbsuite/test/tools/lldb-vscode/ (diff)
The file was modifiedlldb/tools/lldb-vscode/JSONUtils.h (diff)
The file was modifiedlldb/tools/lldb-vscode/lldb-vscode.cpp (diff)
The file was modifiedlldb/tools/lldb-vscode/package.json (diff)
The file was modifiedlldb/tools/lldb-vscode/JSONUtils.cpp (diff)
The file was removedlldb/test/API/tools/lldb-vscode/runInTerminal/
The file was modifiedlldb/tools/lldb-vscode/VSCode.cpp (diff)
The file was modifiedlldb/packages/Python/lldbsuite/test/tools/lldb-vscode/ (diff)
The file was removedlldb/test/API/tools/lldb-vscode/runInTerminal/main.c
The file was removedlldb/test/API/tools/lldb-vscode/runInTerminal/Makefile
Commit c05095cd6865a95ee848cd95d11643969a81a241 by Vitaly Buka
[Asan] Don't crash if metadata is not initialized


AsanChunk can be uninitialized yet just after return from the secondary
allocator. If lsan starts scan just before metadata assignment it can
fail to find corresponding AsanChunk.

It should be safe to ignore this and let lsan to assume that
AsanChunk is in the beginning of the block. This block is from the
secondary allocator and created with mmap, so it should not contain
any pointers and will make lsan to miss some leaks.

Similar already happens for primary allocator. If it can't find real
AsanChunk it falls back and assume that block starts with AsanChunk.
Then if the block is already returned to allocator we have  garbage in
AsanChunk and may scan dead memory hiding some leaks.
I'll fix this in D87135.

Reviewed By: morehouse

Differential Revision:
The file was addedcompiler-rt/test/asan/TestCases/lsan_crash.cpp
The file was modifiedcompiler-rt/lib/asan/asan_allocator.cpp (diff)
Commit 27650a5fed14a99b5c3640444abb0012ca28f3fb by Vitaly Buka
[NFC][Asan] Remove Debug code

Used for

Reviewed By: morehouse

Differential Revision:
The file was modifiedcompiler-rt/lib/asan/asan_allocator.cpp (diff)
The file was modifiedcompiler-rt/lib/lsan/lsan_common.cpp (diff)
The file was modifiedcompiler-rt/lib/sanitizer_common/sanitizer_allocator_combined.h (diff)
The file was modifiedcompiler-rt/lib/sanitizer_common/sanitizer_allocator_primary64.h (diff)
The file was modifiedcompiler-rt/lib/sanitizer_common/sanitizer_allocator_primary32.h (diff)