fresh: update to 0.3.9
- Bump version from 0.3.8 to 0.3.9
- Update CARGO_WRKSRC from crates/fresh-editor to workspace root
(upstream moved Cargo.lock to repo root in this release)
- Regenerate distinfo checksums
Add Pre-Optimization FunctionPropertiesStatistics Pass - All Properties (#199293)
Adding a PreOptimization pass for function properties that provides the
statistics preoptimization without leading to timeouts (also thanks to
https://github.com/llvm/llvm-project/pull/198940 and internal changes on the faulty target)
First iteration led to timeouts so it got reverted
https://github.com/llvm/llvm-project/pull/188837
(UPDATE) Through a flame graph proved that changes in
https://github.com/llvm/llvm-project/pull/198940 , mainly the change
inside the loop, was the one responsible for the timeout. Flame graph spent a majority of the time on updateForBB, and it's the only part there could be a blocker. Furthermore, target was fixed internally.
Previous iteration tried to get only some of the statistics, but managed
to prove locally that it's not necessary to distinguish between them
https://github.com/llvm/llvm-project/pull/199073 since the changes mentioned previously were good enough
devel/py-sortinghat: take maintainership and update to 1.14.3
Reviewed by: kai
Approved by: lwhsu (mentor, implicitly)
Differential Revision: https://reviews.freebsd.org/D57151
www/py-grimoirelab: take maintainership and update to 1.20.3
This also covers updating all its dependencies, most of which
are only used by www/py-grimoirelab.
Reviewed by: kai
Approved by: lwhsu (mentor, implicitly)
Differential Revision: https://reviews.freebsd.org/D57131
sysutils/edk2: Depend on GCC at build time only
EDK2 produces self-contained binary runtime data which do not require GCC at
runtime, but only at build time.
Reviewed by: fuz
MFH: 2026Q2
Differential Revision: https://reviews.freebsd.org/D57187
(cherry picked from commit 64e6ea052e3a1b183f83867e303b289fe1eb88e1)
sysutils/edk2: Depend on GCC at build time only
EDK2 produces self-contained binary runtime data which do not require GCC at
runtime, but only at build time.
Reviewed by: fuz
MFH: 2026Q2
Differential Revision: https://reviews.freebsd.org/D57187
[DebugInfo] Introduce DW_AT_LLVM_language_dialect (#194898)
This PR introduces an LLVM vendor DWARF attribute on compile units that
carries an optional target-specific language dialect enumerator,
distinct from DW_LANG_*. The intent of this addition is to allow a DWARF
consumer to differentiate the source programming language from the
programming model (e.g., CUDA/SIMT, Tile, etc.). This concept could also
be used to differentiate OpenMP, or other parallel models, from host
language.
As older languages adopt newer programming models, there's no need to
introduce a new language enumerator to encode that representation;
rather, the model can be encoded as a dialect and treated as a
refinement to the source language being compiled. For ease of
extensibility, we've decided to represent the value of this new dialect
attribute as a string.
Code/comments/description were developed with LLM assistance.
[2 lines not shown]
py-tox: updated to 4.54.0
Features - 4.54.0
Declare the runtime dependencies of the tox.pytest plugin (pytest, devpi-process and pytest-mock) under a new testing extra, so plugin authors can pull them in via tox[testing] - by @gaborbernat.
Bug fixes - 4.54.0
Extend the generated TOML schema to cover every replace table form (env, ref, posargs, glob, if), including conditional replacements used inside commands. A guard test asserts the schema stays in sync with the loader implementation so future replace types cannot be added without a corresponding schema entry.
x86: use 0x40000010 cpuid leaf only on vmware and kvm
specifically, do not use it on nvmm.
these hypervisor cpuid leafs are basically hypervisor-specific.
(there was a proposal on commonizing these hypervisor leafs. [1]
but it doesn't seem agreed on.)
this cpuid leaf 0x40000010 was originally from vmware. although it
seems more common to use the GETHZ (45) hypercall instead these days.
kvm seems to implement it as well. (via qemu vmware-cpuid-freq)
i personally haven't tested this on either vmware or kvm.
for nvmm (netbsd), the leaf has been implemented in 2025. [2]
and then the lapic bit has been disabled in 2026. [3] that is,
we had no releases with it enabled. even if you are running the
-current version of nvmm, it's better to avoid using this leaf
[5 lines not shown]
nvmm: remove cpuid leaf 0x40000010
* given the lapic bit disabled, (PR/59424) [1]
this leaf doesn't seem to have much benefit anymore.
as nvmm is used in other platforms, (dragonfly bsd)
it's better to avoid guest ABI changes without clear benefits.
* I couldn't find any documenation about what RBX=0 means.
(vmware or kvm)
we can revisit this when/if someone comes up with a better
implementation. (probably userland-assisted one)
discussed on source-changes-d. [2]
reviewed by Taylor R Campbell.
[1] https://mail-index.netbsd.org/source-changes/2026/05/01/msg161786.html
[2] https://mail-index.netbsd.org/source-changes-d/2026/05/01/msg014654.html
gtk3: Make building wayland support conditional on GLAMOREGL on NetBSD.
While this seems... weird, at best, due to Historical Reasons
building libEGL was dependent on building the X server with GLAMOR
support in NetBSD. This is no longer true, but some problems linger
(e.g. with libepoxy in the base system).
As a special hack, for NetBSD with native X only, disable Wayland
support if the GLAMOR extension isn't enabled.
PR pkg/60295 x11/gtk3 does not build on NetBSD/macppc
Sync the nexthop comperators in rde_rib.c and kroute.c
While nexthop_cmp() already looked for the scope_id for link-local IPv6
nexthops, knexthop_compare() did not.
Reported by 7Asecurity
OK tb@
security/c-siphash: Add new port
Streaming-capable SipHash Implementation
WWW: https://c-util.github.io/c-siphash
PR: 294569
Co-authored-by: Max Brazhnikov <makc at FreeBSD.org>
