Skip to content

Tags: audulus/lyte

Tags

0.33

Toggle 0.33's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Merge pull request #20 from izaak/literal-suffixes

Add typed numeric literal suffixes

0.32

Toggle 0.32's commit message
Merge branch 'main' of https://github.com/audulus/lyte

0.31

Toggle 0.31's commit message
Update crate dependency versions

0.30

Toggle 0.30's commit message
Fix nested macro expansion panic

0.29

Toggle 0.29's commit message
Add require clauses and post-monomorph body safety checks

Introduces `require <expr>` clauses on function declarations, checked by
the safety checker at each call site and assumed true inside the body.
Adds a second safety-check pass after monomorphization so that bodies of
`[T; N]` generic functions are verified with concrete sizes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0.28

Toggle 0.28's commit message
Merge branch 'main' of https://github.com/audulus/lyte

0.27

Toggle 0.27's commit message
Run freeverb FFI benchmark in macOS CI

Add a step to the build-macos job that runs benchmark/run-freeverb.sh
(3 runs, 10000 iterations) after the LLVM build+test, and posts the
results to the GitHub job summary. This exercises lyte_compiler_compile
— the xcframework codepath the CLI never touches — on every push.

Also: set LIBRARY_PATH in run-freeverb.sh for CI link robustness, and
gitignore the built freeverb_bench binary.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

0.26

Toggle 0.26's commit message
Enable --no-recursion by default in the C FFI

`lyte_compiler_new` is the only construction site exposed to the
xcframework and its only consumer is Audulus, which compiles DSP
code with DAG call graphs. Flipping the default here recovers the
~2x LLVM DSP regression without touching any host call site or
adding FFI surface. The CLI path is unaffected because it calls
`Compiler::new()` directly and still defaults `no_recursion` to
false.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

0.25

Toggle 0.25's commit message
Fix more f-window leaks in stack codegen

Two more instances of the same class of bug the previous commit fixed
(push to f-window, pop from int window):

1. Void-returning function bodies were translated in non-void context
   and then dropped with `StackOp::Drop` unconditionally. If the body's
   last expression was an f32 `let`, the result sat on the float
   window and the int `Drop` didn't pop it. Translate void bodies in
   void context so each block statement goes through the window-aware
   drop path.

2. The extern-call codegen path pushed f32 args directly to the float
   window and emitted `Call`, but `op_call` copies args from the int
   TOS window into the callee's locals. The f32 args were left stuck
   on the float window and the callee read garbage. f32 return
   values were likewise never bridged back. Mirror the
   regular-call path: `FToBitsF` after each f32 arg, `BitsToFF` after
   the call.

Adds two regression tests driven by a CFG-based f-window balance
checker: `f32_window_balanced_across_void_contexts` (hand-crafted
inputs hitting specific codegen paths) and
`f32_window_balanced_across_test_corpus` (sweeps every .lyte file in
`tests/cases/` through the checker). Two golden outputs are updated
to reflect cleaner codegen now that void-ctx body translation doesn't
emit a trailing `i64.const 0; drop`.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

0.24

Toggle 0.24's commit message
Install clang-19 on Linux CI so preserve_none isn't silently dropped

The Linux x86_64 `build` job was installing the `clang` meta-package on
ubuntu-latest, which currently resolves to clang 18.0-59~exp2 (the
released 18.1.3 binary, just labelled with an experimental epoch).
Upstream Clang only added the `__attribute__((preserve_none))` calling
convention attribute in Clang 19 — Clang 18 silently ignores it with a
`-Wunknown-attributes` warning and falls back to System V cc.

Without preserve_none, every handler in src/stack_interp.c is compiled
as a normal System V function: the TOS window scalars (t1, t2, t3) and
nh spill to the caller's stack frame on every dispatch, the `Handler`
calling convention assumed by the typedef no longer matches the actual
generated code, and the musttail dispatch chain corrupts interpreter
state mid-loop. iir_filter.lyte was the first golden test complex
enough to crash the interpreter before its `assert(matches == 8)`
ever ran — its diff showed `compilation successful` with no
`assert(true)` line, exactly what a mid-loop crash produces. (Build
#1238 attempt #1, build job log at 19:07.)

The aarch64 macOS jobs and the local dev loop on Apple Silicon never
saw this because Apple Clang 21 ships an Apple fork that supports
preserve_none on both aarch64 and x86_64 darwin. Reproduced the
clang-18 warning in a colima x86_64 ubuntu container, and confirmed
that installing clang-19 from apt.llvm.org compiles src/stack_interp.c
with zero warnings.

Two changes:

1. `.github/workflows/rust.yml` build job — install clang-19 from
   apt.llvm.org and set `CC: clang-19`. The clang-19+ packages aren't
   in Ubuntu 24.04's default repos, so the apt source has to come from
   apt.llvm.org. The job-level `CC` env var makes the cc crate pick
   clang-19 for the cli/build.rs detection, which is what flips
   `has_stack_interp` on and lets the stack VM golden tests run.

2. `build.rs` stack interpreter compile — add
   `-Werror=unknown-attributes`. Promoting the `preserve_none ignored`
   warning to a hard error means the next time someone tries to build
   with a clang that doesn't grok the attribute, the build fails
   loudly instead of producing a subtly broken interpreter that
   crashes only on workloads complex enough to expose the corruption.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>