The 15-entry list of (category_name, add_signatures_fn) in builtin_categories() (lines 73–87) is the same list that BUILTIN_SIGNATURES LazyLock walks at lines 49–63. Adding a new builtin sub-module now requires updating both places. The new test_categories_cover_every_signature guards one direction (signatures present but category missing), so a forgotten registration in builtin_categories() will fail the test — but it would be cleaner to drive both from a single shared &[(name, fn)] constant and have BUILTIN_SIGNATURES iterate over it. Not a bug, just drift bait.

2. Silent parse failures in crates/lsp/src/words.rs:collect_stdlib (lines 75–95)

let program = parser.parse().ok()?; silently drops any stdlib module that fails to parse — the entry just vanishes from the seq/listWords response with no log. If a stdlib file regresses, an editor user sees missing words and there is no breadcrumb in the LSP log. A tracing::warn! on the parse error before discarding would make this debuggable. Same for get_stdlib(module)? returning None (shouldn't happen, since the name came from stdlib_module_names(), but worth at least an expect).

Nothing blocking.

Reviewed the diff. Two things worth flagging, both minor; correctness and tests look fine otherwise. **1. Duplicated sub-module list in `crates/compiler/src/builtins.rs`** The 15-entry list of `(category_name, add_signatures_fn)` in `builtin_categories()` (lines 73–87) is the same list that `BUILTIN_SIGNATURES` LazyLock walks at lines 49–63. Adding a new builtin sub-module now requires updating both places. The new `test_categories_cover_every_signature` guards one direction (signatures present but category missing), so a forgotten registration in `builtin_categories()` will fail the test — but it would be cleaner to drive both from a single shared `&[(name, fn)]` constant and have `BUILTIN_SIGNATURES` iterate over it. Not a bug, just drift bait. **2. Silent parse failures in `crates/lsp/src/words.rs:collect_stdlib` (lines 75–95)** `let program = parser.parse().ok()?;` silently drops any stdlib module that fails to parse — the entry just vanishes from the `seq/listWords` response with no log. If a stdlib file regresses, an editor user sees missing words and there is no breadcrumb in the LSP log. A `tracing::warn!` on the parse error before discarding would make this debuggable. Same for `get_stdlib(module)?` returning `None` (shouldn't happen, since the name came from `stdlib_module_names()`, but worth at least an `expect`). Nothing blocking.

navicore added 1 commit

2026-05-02 04:34:34 +00:00

review response

CI - Linux / CI - Linux x86_64 (pull_request) Failing after 2m57s

Details

e1892b4ad2

navicore added 1 commit

2026-05-02 04:41:15 +00:00

fix ci/cd

CI - Linux / CI - Linux x86_64 (pull_request) Failing after 7m12s

Details

b17ce29bcd