misc/py-numcodecs: Update to 0.16.5
- Update DISTVERSION from 0.13.0 to 0.16.5
- Remove PORTREVISION as we are updating to a new version
- Update BUILD_DEPENDS: add cython>=3.0 and setuptools-scm>=6.2, keep py-cpuinfo
- Update RUN_DEPENDS: use numpy>=1.24 (instead of numpy1>=1.16), add typing-extensions, keep msgpack and zfp
- Add TEST_DEPENDS with pytest, pytest-cov, and pyzstd (tests as of 0.16.5)
- Update distinfo with new SHA256 and SIZE checksums
- Add patch to remove deprecated 'license' field from pyproject.toml for compatibility
Co-authored-by: Copilot <223556219+Copilot at users.noreply.github.com>
[Clang] Reject __annotation on unsupported targets (#193731)
__annotation emits llvm.codeview.annotation intrinsics, which are only
consumed by CodeViewDebug
on Windows and UEFI targets. On other targets the intrinsic is silently
dropped, and codegen
hits an assertion due to wchar_t being 4 bytes (UTF-32) instead of the
expected 2 bytes
(UTF-16).
Fixes #184318
[MemProf] Skip GV `__prof*` during instrumentation (#193354)
The existing filter in `isInterestingMemoryAccess` skips globals named
`__llvm*`, but PGO counter globals are named `__profc_*` (and related
`__profd_*`, `__profvp_*`, etc.), so they bypass the name check, e.g.:
https://github.com/llvm/llvm-project/blob/b48d8a54e29f5f33ef52a4759414126904f01611/llvm/include/llvm/ProfileData/InstrProf.h#L128-L138
The section-based check above catches direct accesses where
`stripInBoundsOffsets` resolves to the GlobalVariable, but fails for
bias-based counter addressing `(inttoptr(add(ptrtoint(__profc_),
bias)))` which the strip cannot see through.
This causes MemProf to instrument PGO counter updates, inflating MGO
binary access profiles proportionally to __llvm_prf_cnts section size.
Filtering `__prof` prefixed globals closes this gap.
RFC: we have confirmed `__prof*` are dead weight, whether we should
[4 lines not shown]
[CIR] FlattenCFG: accept cir.trap as a ternary region terminator (#194497)
The CIRTernaryOpFlattening pattern only accepted cir.yield and
cir.unreachable as the terminator of a ternary region. Any other
terminator caused a verifier error ("unexpected terminator in ternary
false region") and aborted the backend with "IR failed to verify after
pattern application".
Real-world C++ code that uses the libc++ assertion macros hits this
path: _LIBCPP_ASSERT_NON_NULL expands to `cond ? (void)0 :
__builtin_trap()`, which lowers to a `cir.ternary` whose false region
ends in `cir.trap`. This is structurally identical to the
`cir.unreachable` case (both are non-returning Terminators), so the
flattening pattern just needs to leave the trap in place rather than
trying to rewrite it into a branch to the continue block.
Concretely this is blocking ~1,510 libc++ tests (~17% of the suite) that
all failed with the same diagnostic at construct_at.h, sample.h, and
pop_heap.h.
[2 lines not shown]
[libc][thread] detect self-join and mutual-join deadlock (#194891)
Fix #194034.
Detect the deadlock cases of mutual thread joining.
Required by
`libcxx/test/std/thread/thread.jthread/join.deadlock.pass.cpp`
Assisted-by: Codex with gpt-5.5 high fast
[dsymutil] Fix ODR type uniquing for -gsimple-template-names (#194501)
With -gsimple-template-names (now the default on macOS with deployment
target >= 26), template types like vector<int> and vector<float> both
get DW_AT_name("vector") in DWARF, with template parameters encoded only
as DW_TAG_template_type_parameter children.
Previously, dsymutil used only DW_AT_name for ODR type uniquing, causing
different template specializations to collide. This PR fixes that by
reconstructing template parameter information from child DIEs when the
type name does not already contain template parameters.
The reconstructed name is used only for uniquing and not emitted into
the output DWARF. The parallel DWARF linker already handled this
correctly via SyntheticTypeNameBuilder.
rdar://175115639
[llvm-dwp] Replace MCStreamer with direct ELF writer for zero-copy output (#192112)
Replace the MCStreamer-based output pipeline with a lightweight direct
ELF writer (DWPWriter). Section data is stored as zero-copy StringRef
chunks pointing to the mmap'd input files, and written as a minimal
ELF64 relocatable object directly to disk.
## Rationale
The MCStreamer pipeline copies all section data into 16KB MCDataFragment
blocks, accumulates them in memory, then writes everything out during
MCAssembler::Finish(). This can be cause lots of memory pressure and
slow down llvm-dwp.
For instance, on a 3.3GB DWP file, this translates to rougly ~3.3GB of
heap allocation and two full copies of the data.
The new DWPWriter avoids this via:
- emitBytes() stores a StringRef chunk (zero-copy, no allocation)
- emitIntValue() writes to a small per-section buffer (index tables)
[16 lines not shown]
[clang-tidy] Fix some false positive in bugprone-move-forwarding-reference (#191435)
In the following case:
template <typename T, typename U>
void shocase(U&& SomeU) {
[SomeU] () { T SomeT(std::move(SomeU)); };
}
We use to flag the move as a forward, while the lambda captures SomeU by
copy, which makes the move valid.
[LangRef] asm clobber constrains: '~memory' allows reads and synchronization (#150191)
I was not sure what the best way is for talking about "synchronization effects".
