Skip to content

Upgrade libhegel from 0.45.0 to 0.47.1 - #34

Open
esauro wants to merge 2 commits into
mainfrom
libhegel-0.47.1
Open

esauro wants to merge 2 commits into
mainfrom
libhegel-0.47.1

Conversation

@esauro

@esauro esauro commented Oct 22, 2026

Copy link
Copy Markdown
Contributor

libhegel 0.46 changed every string parameter and output of the C ABI to hegel_string_t (a {data, len} struct, by value for required strings, by nullable pointer where absent is meaningful, as a contiguous array for name lists), and renamed hegel_generate_string_result_free to hegel_owned_string_free. Both bindings marshal strings that way now:

  • RealLibhegel (FFM): a STRING_LAYOUT struct layout in the descriptors, str/strPtr/strArray helpers for inputs, readString/readStringPtr for outputs; hegel_context_last_error returns the struct by value, so its downcall takes an arena as allocator.
  • JnaLibhegel (JNA): a HegelString Structure (with ByValue) replaces the String parameters and the BufferResult struct; strArray writes the struct array and the string bytes into one Memory block so nothing inside it can be collected during the call.

A null Java string crosses as {NULL, 0} by value, which the engine reads as an empty string, so a null regex pattern is now the empty pattern rather than E_INVALID_ARG; the edge tests say so, and new round-trip tests send a label, an origin, a database path and name lists through the engine and read the origin back.

One behaviour change reaches the shared suite: since 0.45.2 a run that never generates a valid case ends in the engine's Unsatisfiable error even with the filter-too-much health check suppressed, instead of passing vacuously.

libhegel 0.46 changed every string parameter and output of the C ABI to
hegel_string_t (a {data, len} struct, by value for required strings, by
nullable pointer where absent is meaningful, as a contiguous array for
name lists), and renamed hegel_generate_string_result_free to
hegel_owned_string_free. Both bindings marshal strings that way now:

- RealLibhegel (FFM): a STRING_LAYOUT struct layout in the descriptors,
  str/strPtr/strArray helpers for inputs, readString/readStringPtr for
  outputs; hegel_context_last_error returns the struct by value, so its
  downcall takes an arena as allocator.
- JnaLibhegel (JNA): a HegelString Structure (with ByValue) replaces the
  String parameters and the BufferResult struct; strArray writes the
  struct array and the string bytes into one Memory block so nothing
  inside it can be collected during the call.

A null Java string crosses as {NULL, 0} by value, which the engine reads
as an empty string, so a null regex pattern is now the empty pattern
rather than E_INVALID_ARG; the edge tests say so, and new round-trip
tests send a label, an origin, a database path and name lists through
the engine and read the origin back.

One behaviour change reaches the shared suite: since 0.45.2 a run that
never generates a valid case ends in the engine's Unsatisfiable error
even with the filter-too-much health check suppressed, instead of
passing vacuously.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
DRMacIver added a commit to hegeldev/hegel that referenced this pull request Oct 22, 2026
The Java frontend (the dev.hegel:hegel, dev.hegel:hegel-jna and
dev.hegel:hegel-lowlevel Maven artifacts) now lives in frontends/java,
built and tested against the in-tree libhegel instead of a pinned GitHub
release.

The bindings are ported to the current C ABI: ordinary string arguments
are borrowed hegel_string_t values (an FFM struct layout passed by value,
a JNA Structure.ByValue), optional strings and name lists cross as
pointers to and contiguous arrays of that struct, hegel_context_last_error
returns the struct by value, hegel_generate_string writes a
hegel_owned_string_t freed with hegel_owned_string_free, and strings may
contain NUL. The port follows hegeldev/hegel-java#34.

scripts/engine.py replaces scripts/fetch_natives.py: Maven stages the
host's cargo build as the bundled native for development and the tests,
and every platform's library from the libhegel GitHub release under the
release profile; BuildInfo.ENGINE_VERSION is generated from
libhegel/Cargo.toml rather than filtered from a pom property, so there is
no engine pin to keep in step. CI gains frontend-java.yml (the reactor on
JDK 22 and 25, hegel-jna on 17 and 21, macOS and Windows, javadoc), the
lint job runs spotless, and ci.yml publishes the three artifacts to Maven
Central from the frontends/java/<version> tag after the libhegel
binaries it bundles are on the GitHub release. release.py learns Maven
poms.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant