Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

vera/wasm/inference.py (1)

328-338: ⚠️ Potential issue | 🟠 Major

Mirror these math built-ins in _infer_fncall_vera_type.

Line 328 adds WASM inference, but Vera-type inference still has no corresponding branch for these functions, so type inference can fall through to None in downstream rewriting paths.

Proposed fix

@@
         if call.name in ("sqrt", "pow"):
             return "Float64"
+        if call.name in (
+            "log", "log2", "log10",
+            "sin", "cos", "tan", "asin", "acos", "atan", "atan2",
+            "pi", "e", "float_clamp",
+        ):
+            return "Float64"
+        if call.name in ("sign", "clamp"):
+            return "Int"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@vera/wasm/inference.py` around lines 328 - 338, The Vera-type inference
function _infer_fncall_vera_type is missing the branch for the math built-ins
added to WASM inference; add a corresponding conditional that checks expr.name
for ("log", "log2", "log10", "sin", "cos", "tan", "asin", "acos", "atan",
"atan2", "pi", "e", "float_clamp") and returns "f64", and another for ("sign",
"clamp") returning "i64", so _infer_fncall_vera_type mirrors the WASM logic and
avoids falling through to None.

ROADMAP.md (1)

3-3: ⚠️ Potential issue | 🟡 Minor

Version anchors are stale against this release update.

Line 3 still anchors current capabilities to v0.0.108, and Line 269 still says “as of v0.0.115” despite this PR targeting v0.0.116. Please synchronise both anchors so the roadmap remains historically accurate.

Suggested fix

-Vera v0.0.108 delivers a complete compiler pipeline ...
+Vera v0.0.116 delivers a complete compiler pipeline ...

-**810+ commits, 115 tagged releases (as of v0.0.115), 3,387 tests, 96% coverage, 77 conformance programs, 30 examples, 13 spec chapters.**
+**810+ commits, 116 tagged releases (as of v0.0.116), 3,387 tests, 96% coverage, 77 conformance programs, 30 examples, 13 spec chapters.**

As per coding guidelines **/*.md: review Markdown for factual accuracy and outdated information.

Also applies to: 269-269

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ROADMAP.md` at line 3, Update the stale version anchors in the roadmap:
replace the first occurrence referencing "v0.0.108" and the later note that
reads "as of v0.0.115" so they both reflect the actual target release
"v0.0.116"; edit the lines containing those exact version strings to "v0.0.116"
(search for "v0.0.108" and "v0.0.115" in ROADMAP.md and update them) to keep the
historical record accurate.

spec/12-runtime.md (1)

48-57: ⚠️ Potential issue | 🟡 Minor

Import-condition text is now outdated after adding pure math imports.

Line 67 still says imports are emitted only for effect operations, but Line 48–57 adds host imports for pure math builtins (log*, trig, atan2). Please widen this sentence to cover host-backed builtins as well.

Suggested wording

-Imports are only emitted when the program actually uses the corresponding effect operations. A pure program produces a module with no imports.
+Imports are only emitted when the program actually uses the corresponding host-backed operations (effect operations and selected pure builtins). A pure program that uses only inlined builtins produces a module with no imports.

As per coding guidelines spec/**/*.md: Language specification files must be factually accurate against the codebase.

Also applies to: 67-67

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@spec/12-runtime.md` around lines 48 - 57, Update the import-condition wording
around the sentence at line 67 to reflect that imports are emitted not only for
effectful operations but also for host-backed pure builtins (e.g., vera.log,
vera.log2, vera.log10, vera.sin, vera.cos, vera.tan, vera.asin, vera.acos,
vera.atan, vera.atan2); change the sentence to state that imports are emitted
for operations that require host backing (effectful ops and host-backed
builtins) so the spec matches the added pure math imports listed in the table.

spec/09-standard-library.md (1)

866-867: ⚠️ Potential issue | 🟠 Major

Correct pi/e to zero-argument signatures.

These entries still document Unit -> Float64, but this PR’s API uses zero-arg calls (pi(), e()). Please keep the spec aligned with the implemented call form.

Suggested fix

-| `pi` | `Unit -> Float64` | `3.141592653589793` |
-| `e` | `Unit -> Float64` | `2.718281828459045` |
+| `pi` | `() -> Float64` | `3.141592653589793` |
+| `e` | `() -> Float64` | `2.718281828459045` |

As per coding guidelines: “spec/**/*.md: Language specification. Review for factual accuracy and broken code examples.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@spec/09-standard-library.md` around lines 866 - 867, Update the documented
signatures for the constants pi and e from the current "Unit -> Float64" to the
zero-argument call form used by the implementation (e.g., "() -> Float64") so
the spec shows the actual call form pi() and e(); modify the table entries for
the symbols "pi" and "e" to use the zero-argument signature and corresponding
example call form.

TESTING.md (1)

76-76: ⚠️ Potential issue | 🟡 Minor

Update the stale conformance count in the runner snippet.

This file now states 385 conformance tests here, but the “Via pytest” snippet later still says 375. Please make those counts consistent.

As per coding guidelines: “**/*.md: Review Markdown files for factual accuracy against the codebase, broken links, and outdated information.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@TESTING.md` at line 76, Update the mismatched conformance test count in the
"Via pytest" runner snippet so it matches the table entry for
`test_conformance.py` (which lists 385 tests); locate the "Via pytest"
code/snippet that currently says 375 and change that numeric literal to 385 so
both references to `test_conformance.py` are consistent.

tests/test_codegen.py (4)

10487-10496: ⚠️ Potential issue | 🟠 Major

Add lo > hi coverage for clamp to pin edge semantics.

The current cases do not exercise the inverted-bound branch, so regressions there would go undetected.

Proposed fix

         cases = [
             # (v, lo, hi, expected)
             (5, 0, 10, 5),      # within range → v
             (-3, 0, 10, 0),     # below lo → lo
             (15, 0, 10, 10),    # above hi → hi
+            (5, 10, 0, 0),      # lo > hi semantics -> hi
             (-10, -5, 5, -5),   # negative range, below
             (100, -5, 5, 5),    # negative range, above
             (7, 7, 7, 7),       # singleton (lo == hi == v)
             (0, 0, 0, 0),       # zero singleton
         ]

As per coding guidelines "Add codegen/runtime tests in tests/test_codegen.py for built-in functions — cover normal cases, edge cases (empty inputs, zero values), and composition with other built-ins".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/test_codegen.py` around lines 10487 - 10496, Add test cases to the
existing "cases" list for the clamp tests to cover the inverted-bound branch (lo
> hi) so pin-edge semantics are exercised; update the test vector list near the
clamp checks (the "cases" variable used by the clamp tests) with entries where
lo > hi (e.g., v within, below, and above the inverted range) to assert the
expected pinned value, ensuring the clamp function's inverted-bound behavior is
validated.

---

10388-10390: ⚠️ Potential issue | 🟡 Minor

Harden the log import assertion to avoid substring false-positives.

assert "$vera.log" in result.wat can pass when only $vera.log2/$vera.log10 is present. Match the import token exactly.

Proposed fix

-        assert "$vera.log" in result.wat
+        assert any(
+            '(import "vera" "log"' in line
+            for line in result.wat.splitlines()
+        )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/test_codegen.py` around lines 10388 - 10390, The assertion for the
"$vera.log" import is too permissive and can match "$vera.log2" or
"$vera.log10"; update the test in tests/test_codegen.py to assert the exact
import token instead of a substring match—e.g., check result.wat for a
whole-token match of "$vera.log" (use a word-boundary/regex like \$vera\.log\b
or otherwise ensure surrounding non-word characters) while keeping the existing
checks for "$vera.log2" and "$vera.log10".

---

10516-10521: ⚠️ Potential issue | 🟠 Major

Add lo > hi coverage for float_clamp as well.

float_clamp has the same uncovered inverted-bound edge case.

Proposed fix

         cases = [
             (0.5, 0.0, 1.0, 0.5),
             (3.5, 0.0, 1.0, 1.0),
             (-3.5, 0.0, 1.0, 0.0),
             (-1.5, -2.0, -1.0, -1.5),  # negative in-range
+            (0.5, 2.0, 1.0, 1.0),       # lo > hi semantics -> hi
         ]

As per coding guidelines "Add codegen/runtime tests in tests/test_codegen.py for built-in functions — cover normal cases, edge cases (empty inputs, zero values), and composition with other built-ins".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/test_codegen.py` around lines 10516 - 10521, The float_clamp tests are
missing coverage for the inverted-bound case (lo > hi); update the cases list
used by the float_clamp test to include a tuple that represents this edge
(value, lo, hi, expected) mirroring the integer clamp inverted-bound entry
(i.e., add an entry where lo > hi and set the expected result to whatever the
float_clamp implementation returns in that scenario), referencing the
float_clamp test's cases variable so the test suite exercises the lo>hi
behavior.

---

10415-10434: ⚠️ Potential issue | 🟠 Major

atan2 ordering is not truly validated, and asin/acos are not exercised.

Using atan2(1.0, 1.0) is symmetric, so swapped argument order would still pass. The test docstring also claims asin/acos coverage but the body never calls them.

Proposed fix

     def test_inverse_trig_at_known_points(self) -> None:
-        """asin(0)==0, acos(1)==0, atan(1)≈π/4, atan2(1,1)≈π/4.
+        """asin/acos known points and non-symmetric atan2(y, x) order."""
+        import math
         source = """\
 public fn main(-> `@Float64`)
   requires(true) ensures(true) effects(pure)
 {
-  atan(1.0) - atan2(1.0, 1.0)
+  asin(0.0) + acos(1.0) + atan2(1.0, -1.0)
 }
 """
         result = _compile_ok(source)
+        assert "$vera.asin" in result.wat
+        assert "$vera.acos" in result.wat
         assert "$vera.atan" in result.wat
         assert "$vera.atan2" in result.wat
         v = execute(result, fn_name="main").value
-        # Both values equal π/4; difference should be exactly 0.
-        assert v == 0.0, f"atan(1) vs atan2(1,1) disagreement: {v}"
+        assert abs(v - math.atan2(1.0, -1.0)) < 1e-12

As per coding guidelines "Add codegen/runtime tests in tests/test_codegen.py for built-in functions — cover normal cases, edge cases (empty inputs, zero values), and composition with other built-ins".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/test_codegen.py` around lines 10415 - 10434, The test
test_inverse_trig_at_known_points currently only compares atan(1.0) vs
atan2(1.0, 1.0) (a symmetric case) and never exercises asin/acos; update the
test body (function main) to call and assert asin(0.0)==0.0 and acos(1.0)==0.0
and to include a non-symmetric atan2 call to validate argument ordering (e.g.,
compute atan2(1.0, -1.0) and compare to the expected sign/value relative to
atan2(-1.0, 1.0) or known constants), and add asserts that "$vera.asin" and
"$vera.acos" appear in result.wat along with existing "$vera.atan" and
"$vera.atan2"; modify the execute/result assertions in
test_inverse_trig_at_known_points to check these new numeric expectations and
wat symbols so the test truly covers asin/acos and verifies atan2 argument
ordering.

tests/test_browser.py (1)

504-599: ⚠️ Potential issue | 🟠 Major

Add domain-edge parity tests for the new math built-ins.

The new suite is strong on happy paths, but it still misses boundary/domain cases (log(-1.0), log(0.0), asin(2.0), acos(2.0)). Without these, regressions in non-trapping NaN/±inf behaviour can slip through.

Suggested test additions

+    def test_log_negative_is_nan(self, tmp_path: Path) -> None:
+        source = '''\
+public fn main(-> `@Unit`)
+  requires(true) ensures(true) effects(<IO>)
+{
+  IO.print(float_to_string(log(-1.0)))
+}
+'''
+        wasm_path, _ = _compile_vera(source, tmp_path)
+        node = _run_node(wasm_path)
+        import math
+        assert math.isnan(float(node["stdout"]))
+
+    def test_log_zero_is_neg_inf(self, tmp_path: Path) -> None:
+        source = '''\
+public fn main(-> `@Unit`)
+  requires(true) ensures(true) effects(<IO>)
+{
+  IO.print(float_to_string(log(0.0)))
+}
+'''
+        wasm_path, _ = _compile_vera(source, tmp_path)
+        node = _run_node(wasm_path)
+        import math
+        assert math.isinf(float(node["stdout"])) and float(node["stdout"]) < 0.0

As per coding guidelines "DO flag: Missing edge cases for new compiler features".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/test_browser.py` around lines 504 - 599, Add domain-edge parity tests
to TestBrowserMathBuiltins that exercise log(-1.0), log(0.0), asin(2.0) and
acos(2.0): for each case compile/run the same way as existing tests using
_compile_vera and _run_node with small Vera programs that print float_to_string
of the expression, parse node["stdout"] and assert the runtime produces the
expected IEEE results (use math.isnan for NaN cases: log(-1.0), asin(2.0),
acos(2.0); and math.isinf plus sign check for -inf from log(0.0)). Name the new
test functions clearly (e.g. test_log_domain_edges, test_asin_acos_domain_edges)
and follow the same pattern as test_log_identity and others so they run under
the same test harness.

vera/codegen/api.py (1)

2255-2313: ⚠️ Potential issue | 🔴 Critical

Handle math domain exceptions to prevent runtime traps.

Line 2259 promises IEEE-754-style behaviour, but Line 2280 directly calls py_fn(x). Python raises ValueError for several domain-edge inputs (e.g. log(-1), asin(2)), which currently escape as traps instead of returning Float64 sentinels.

Proposed fix

-        def _math_unary_host(
-            py_fn: Callable[[float], float],
+        def _math_unary_host(
+            op_name: str,
+            py_fn: Callable[[float], float],
         ) -> Callable[[wasmtime.Caller, float], float]:
@@
             def host(_caller: wasmtime.Caller, x: float) -> float:
-                return py_fn(x)
+                try:
+                    return py_fn(x)
+                except ValueError:
+                    # Match JS/IEEE-style non-trapping behaviour.
+                    if op_name in {"log", "log2", "log10"} and x == 0.0:
+                        return float("-inf")
+                    return float("nan")
             return host
@@
-                    _math_unary_host(py_fn), access_caller=True,
+                    _math_unary_host(op_name, py_fn), access_caller=True,
                 )

#!/bin/bash
# Verify Python math domain behaviour that currently propagates as traps.
python - <<'PY'
import math
cases = [
    ("log", -1.0),
    ("log", 0.0),
    ("log2", 0.0),
    ("asin", 2.0),
    ("acos", 2.0),
]
for name, x in cases:
    fn = getattr(math, name)
    try:
        print(f"{name}({x}) -> {fn(x)!r}")
    except Exception as exc:
        print(f"{name}({x}) raised {type(exc).__name__}: {exc}")
PY

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@vera/codegen/api.py` around lines 2255 - 2313, Wrap the direct calls to math
functions in _math_unary_host.host and in host_atan2 with try/except so Python
domain/overflow exceptions are converted to IEEE-754 sentinels: catch ValueError
and return float("nan"); catch OverflowError and return math.copysign(math.inf,
x) (for unary host) or math.copysign(math.inf, y) (for host_atan2); keep using
the same identifiers (_math_unary_host, host, host_atan2, linker.define_func) so
the wrappers still get registered via linker.define_func.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

tests/test_codegen.py (1)

10420-10441: ⚠️ Potential issue | 🟠 Major

atan2 argument-order is still not actually validated

Line 10431 uses atan2(1.0, 1.0), which is symmetric, so a swapped (x, y) implementation would still pass. This leaves the POSIX (y, x) contract unguarded.

Suggested test fix

     def test_inverse_trig_at_known_points(self) -> None:
-        """asin(0)==0, acos(1)==0, atan(1)≈π/4, atan2(1,1)≈π/4.
+        """asin/acos known points and non-symmetric atan2(y, x) ordering.
 
         Each expression exercises a distinct host import; the final
-        subtraction (atan vs atan2) is zero because both equal π/4,
-        confirming the two share consistent host implementations.
+        value must respect atan2(y, x) argument order.
         """
+        import math
         source = """\
 public fn main(-> `@Float64`)
   requires(true) ensures(true) effects(pure)
 {
-  asin(0.0) + acos(1.0) + (atan(1.0) - atan2(1.0, 1.0))
+  asin(0.0) + acos(1.0) + atan(1.0) + atan2(1.0, -1.0)
 }
 """
         result = _compile_ok(source)
         assert "$vera.asin" in result.wat
         assert "$vera.acos" in result.wat
         assert "$vera.atan" in result.wat
         assert "$vera.atan2" in result.wat
         v = execute(result, fn_name="main").value
-        # asin(0) = 0, acos(1) = 0, atan(1) - atan2(1, 1) = 0 → sum 0.
-        assert v == 0.0, f"inverse-trig identity broken: got {v}"
+        expected = math.asin(0.0) + math.acos(1.0) + math.atan(1.0) + math.atan2(1.0, -1.0)
+        assert abs(v - expected) < 1e-12, f"inverse-trig check failed: got {v}, expected {expected}"

As per coding guidelines "Add codegen/runtime tests in tests/test_codegen.py for built-in functions — cover normal cases, edge cases (empty inputs, zero values), and composition with other built-ins".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/test_codegen.py` around lines 10420 - 10441, The test
test_inverse_trig_at_known_points currently uses symmetric arguments atan2(1.0,
1.0) so a swapped-arg implementation would still pass; change the test to use
asymmetric values (e.g., atan2(0.5, 1.0)) and assert the POSIX contract by
comparing atan2(y,x) to atan(y/x) (for x>0) — update the source string in
test_inverse_trig_at_known_points (and any related asserts that inspect the
compiled wat or execute(result, fn_name="main").value) to use the asymmetric
inputs and the corresponding expected numeric check so that a swapped (x,y)
implementation fails.

spec/12-runtime.md (1)

31-31: ⚠️ Potential issue | 🟡 Minor

Update the subsection prose to match the new import table.

Line 67 still says imports are emitted only for effect operations, but Lines 48-57 now include pure host-backed math imports (vera.log, vera.sin, etc.). Please align the sentence to avoid an internal contradiction.

Suggested fix

-Imports are only emitted when the program actually uses the corresponding effect operations. A pure program produces a module with no imports.
+Imports are only emitted when the program actually uses the corresponding host-backed operations (effect operations and selected pure built-ins). A program that uses only inlined built-ins produces a module with no imports.

As per coding guidelines **/*.md: Review Markdown files for factual accuracy against the codebase, broken links, and outdated information.

Also applies to: 48-57, 67-67

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@spec/12-runtime.md` at line 31, Update the subsection prose so it no longer
claims imports are emitted only for effect operations; instead state that the
module imports host functions for both effectful operations and pure host-backed
built-ins (e.g., vera.log, vera.sin and other math imports shown in the table).
Edit the sentence that currently asserts "imports are emitted only for effect
operations" to explicitly mention pure host-backed math imports and align the
surrounding text with the import table entries (vera.log, vera.sin, etc.) so the
paragraph is factually consistent.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

spec/12-runtime.md (1)

31-67: ⚠️ Potential issue | 🟡 Minor

Resolve the contradictory import-emission statement.

Line 67 still says imports are emitted only for effect operations, but Lines 31 and 48-57 now document pure host-backed math imports. Please align that sentence so the subsection is internally consistent.

Suggested doc fix

-Imports are only emitted when the program actually uses the corresponding effect operations. A pure program produces a module with no imports.
+Imports are only emitted when the program actually uses the corresponding host-backed operations (effect operations and selected pure built-ins such as log/trig). A pure program that uses only inlined built-ins can produce a module with no imports.

As per coding guidelines **/*.md: Review Markdown files for factual accuracy against the codebase, broken links, and outdated information.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@spec/12-runtime.md` around lines 31 - 67, The paragraph stating "Imports are
only emitted when the program actually uses the corresponding effect operations"
contradicts the earlier table that shows pure host-backed built-ins (e.g.
vera.log, vera.sin, vera.atan2) are also imported; update that sentence to say
that imports are emitted for any host-backed features the module uses —
including both effect operations (IO.*, State.*, Random.*, etc.) and pure
host-backed built-ins (e.g. vera.log, vera.sin, vera.cos, vera.atan2) — so the
subsection consistently reflects that a module only imports the host functions
it actually uses.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes