[System] You are a coding assistant for the Ling programming language.

[User] Does the ling CLI use the clap crate for argument parsing?

[Assistant] No. The real `ling` CLI does hand-rolled argument parsing directly inside `src/main.rs` — it is not built on the `clap` crate. There is a `src/cli.rs` file in the repo that defines clap-derive-style structs, which looks exactly like what you'd expect the real CLI definition to be, but it is confirmed dead code: it is never wired into `main()` and never sits on the actual binary's argument-parsing path. If you want to know what a flag really does, you have to read the hand-rolled parsing logic in `src/main.rs`, not `src/cli.rs`.


[System] You are a coding assistant for the Ling programming language.

[User] What does src/cli.rs do in the ling repo?

[Assistant] Less than it appears to. `src/cli.rs` defines clap-derive-style structs that look like the canonical definition of the `ling` CLI's subcommands and flags, but it is verified dead code — it is never referenced from `main()` and never actually parses the arguments the compiled `ling` binary receives. The real argument parsing is hand-rolled directly in `src/main.rs`. Treat `src/cli.rs` as vestigial; don't trust it as documentation of current CLI behavior.


[System] You are a coding assistant for the Ling programming language.

[User] I found src/cli.rs in the ling repo with #[derive(Parser)] structs — can I use that to know what flags ling supports?

[Assistant] Be careful — that file is a trap. `src/cli.rs` uses clap-derive-style structs and reads like the authoritative CLI schema, but it is confirmed dead code: it is never wired into `main()` and never compiled into the actual argument-parsing path of the `ling` binary. The real CLI is hand-rolled arg parsing living in `src/main.rs`, and that hand-rolled logic is the only source of truth for what flags actually exist and what they do.


[System] You are a coding assistant for the Ling programming language.

[User] What crate does ling use to parse `ling run --interp app.ling`?

[Assistant] None — there's no argument-parsing crate involved. `ling` parses its own CLI arguments with hand-rolled logic in `src/main.rs`. It is not built on `clap`, despite the repo containing a `src/cli.rs` file with clap-derive-style structs; that file is dead code that never gets wired into `main()`.


[System] You are a coding assistant for the Ling programming language.

[User] Is src/cli.rs the file I should edit to add a new global flag to ling?

[Assistant] No, editing `src/cli.rs` would have no effect on the compiled binary's behavior. That file defines clap-derive-style structs but is dead code — it's never referenced from `main()` and never part of the actual argument-parsing path. The real CLI argument parsing is hand-rolled directly in `src/main.rs`, so that's the file that actually determines what flags `ling` accepts.


[System] You are a coding assistant for the Ling programming language.

[User] True or false: ling's CLI is defined declaratively with clap derive macros.

[Assistant] False, at least for the code path that actually runs. The repo does contain a `src/cli.rs` with clap-derive-style structs, but it's dead code that's never wired into `main()`. The real, executing CLI in `ling` is hand-rolled argument parsing written directly in `src/main.rs` — no `clap` crate involved in the live path.


[System] You are a coding assistant for the Ling programming language.

[User] Why would ling have a src/cli.rs full of clap structs if it doesn't use clap?

[Assistant] It's leftover/vestigial code — plausibly an earlier or abandoned attempt at a declarative CLI definition. Verified against `src/main.rs`, `src/cli.rs`'s clap-derive-style structs are never wired into `main()` and never sit on the actual argument-parsing path of the compiled binary. The behavior of `ling` is entirely determined by the hand-rolled parsing logic in `src/main.rs`; `src/cli.rs` should be treated as unused and not authoritative.


[System] You are a coding assistant for the Ling programming language.

[User] If I want to add a `--verbose` flag to every ling subcommand, where's the single source of truth for CLI parsing?

[Assistant] `src/main.rs`. That's where `ling`'s hand-rolled argument parsing actually lives and executes. Do not rely on `src/cli.rs` — even though it defines clap-derive-style structs that look like a CLI schema, it's confirmed dead code, never wired into `main()`, and has no effect on what flags the real binary accepts.


[System] You are a coding assistant for the Ling programming language.

[User] Someone told me ling's CLI parsing goes through clap's derive API. Confirm or correct.

[Assistant] Correct that a clap-derive-style definition exists in the repo (`src/cli.rs`), but the claim itself is wrong: that file is dead code and is never wired into `main()`. The CLI that actually ships and runs is hand-rolled argument parsing written directly in `src/main.rs`, with no dependency on the `clap` crate for the live path.


[System] You are a coding assistant for the Ling programming language.

[User] When I see `use clap::Parser` somewhere in the ling repo, does that mean ling.exe's argument parsing depends on clap?

[Assistant] Not necessarily — and in this case, no. That usage lives in `src/cli.rs`, which defines clap-derive-style structs but is confirmed dead code: never wired into `main()`, never part of the compiled binary's actual argument-parsing path. The real CLI behavior comes entirely from hand-rolled parsing logic in `src/main.rs`.


[System] You are a coding assistant for the Ling programming language.

[User] Is there any part of the ling toolchain where clap is actually the live argument parser?

[Assistant] Not in the `ling` CLI itself. `ling`'s real argument parsing in `src/main.rs` is hand-rolled, not clap-based. The only clap-shaped code in the repo is `src/cli.rs`, and it's confirmed dead code — never wired into `main()`, so it never actually parses arguments for the compiled binary.


[System] You are a coding assistant for the Ling programming language.

[User] What are ling's real subcommands and their flags?

[Assistant]
The verified subcommands and flags are:

- `ling run <file.ling> [--interp] [--wasm] [--web] [--device <n>] [-- <program args>]` — runs a program directly (JIT/AOT by default).
- `ling build <file.ling> [--out <path>] [--platform <target>] [--icon <path>] [--pack] [--aot]` — compiles to a standalone executable/package.
- `ling ast <file.ling> [--technical] [--artwork] [--ling] [--all] [--out <path>]` — dumps the AST in different presentation modes; this is an internal debugging/visualization view of the parser output, not something a `.ling` program ever imports or calls at runtime.
- `ling convert <file> [-o <out>] [--no-compression]` — an asset/format conversion utility.

Note: command lines for server-style programs often also show `--listen <addr>` and `--port <n>` after the filename, but those are not flags `ling run` itself parses — see the cli_arg() note below.


[System] You are a coding assistant for the Ling programming language.

[User] Show me a basic usage example for `ling build`.

[Assistant]
`ling build app.ling --out dist/app.exe --platform windows --pack`

The real flags for `ling build <file.ling>` are `--out <path>`, `--platform <target>`, `--icon <path>`, `--pack`, and `--aot`. It compiles the `.ling` source into a standalone executable or package rather than running it directly.


[System] You are a coding assistant for the Ling programming language.

[User] How do I dump the AST of a ling program for debugging, with artwork-style formatting?

[Assistant]
`ling ast myprogram.ling --artwork`

`ling ast <file.ling>` supports the presentation flags `--technical`, `--artwork`, `--ling`, `--all`, and `--out <path>`. These are just different display/dump modes over the parser's AST output for human debugging — a `.ling` program itself never imports or calls this; it's a CLI-only tool.


[System] You are a coding assistant for the Ling programming language.

[User] What flags does `ling convert` take?

[Assistant] `ling convert <file> [-o <out>] [--no-compression]` — it's an asset/format conversion utility. The real flags are `-o <out>` to set the output path and `--no-compression` to disable compression; there's nothing beyond that in the verified flag set.


[System] You are a coding assistant for the Ling programming language.

[User] Does `ling run` have a `--port` flag?

[Assistant] No — `ling run` itself doesn't define or parse a `--port` flag. What actually happens is that `--port <n>` (and `--listen <addr>`) get consumed by application code inside the running `.ling` program itself, via calls like `cli_arg("port", ...)` — this project's own app.ling does exactly that. So `ling run app.ling --port 8440` works, but it's because `app.ling` calls `cli_arg("port", "8440")` at runtime, not because `ling run` has a built-in `--port` flag.


[System] You are a coding assistant for the Ling programming language.

[User] I want to run a server-style ling program on a specific port. What's the command?

[Assistant]
Something like: `ling run server.ling --port 8440`

But be precise about who's parsing that flag: `ling run` itself does not define `--port` as one of its own recognized flags. Instead, the value flows through to the running program, and it's `server.ling`'s own code — via `cli_arg("port", "8440")` — that reads and acts on it. This project's app.ling is exactly this pattern: it uses `cli_arg("listen", ...)` / `cli_arg("port", ...)` internally rather than relying on any global `ling` CLI flag.


[System] You are a coding assistant for the Ling programming language.

[User] Is `--listen` a global ling CLI flag or something application-specific?

[Assistant] It's application-specific, not a global `ling` CLI flag. `--listen <addr>` is consumed by user application code inside the running `.ling` program via `cli_arg("listen", ...)` — this project's own app.ling does this. `ling run` does not itself define and parse `--listen`; it just happens to be a common convention for server-style `.ling` programs to look for that argument via `cli_arg()`.


[System] You are a coding assistant for the Ling programming language.

[User] What's the difference between a flag ling's CLI parses and a flag a .ling program reads via cli_arg?

[Assistant] Flags like `--interp`, `--wasm`, `--web`, and `--device <n>` on `ling run`, or `--out`/`--platform`/`--icon`/`--pack`/`--aot` on `ling build`, are parsed by `ling`'s own hand-rolled argument parser in `src/main.rs` — they change how `ling` itself behaves (which backend to use, where to write output, etc.). By contrast, `--listen <addr>` and `--port <n>` are typically not parsed by `ling` at all; they're read at runtime by the `.ling` program itself via `cli_arg("listen", ...)` / `cli_arg("port", ...)`, as seen in this project's app.ling. Mixing these two categories up is an easy mistake — always check whether a flag changes `ling`'s own behavior or is just being forwarded to the program's own argument reader.


[System] You are a coding assistant for the Ling programming language.

[User] Give me the full verbatim usage line for `ling run`.

[Assistant]
`ling run <file.ling> [--interp] [--wasm] [--web] [--listen <addr>] [--port <n>] [--device <n>] [-- <program args>]`

That's what a typical invocation line looks like in practice, but two of those tokens are not actually flags `ling run` parses itself: `--listen <addr>` and `--port <n>` are consumed by the `.ling` program's own `cli_arg("listen", ...)` / `cli_arg("port", ...)` calls at runtime, not by `ling`'s CLI parser. The flags `ling run` itself recognizes are `--interp`, `--wasm`, `--web`, and `--device <n>`, plus the `--` separator before program args.


[System] You are a coding assistant for the Ling programming language.

[User] Can I pass arbitrary extra arguments to my ling program through `ling run`?

[Assistant] Yes, via `-- <program args>` at the end of `ling run <file.ling> [--interp] [--wasm] [--web] [--listen <addr>] [--port <n>] [--device <n>] [-- <program args>]`. Anything after `--` is passed straight through to the program. Note that things like `--port` and `--listen` are conventionally read by the program itself through `cli_arg("port", ...)` / `cli_arg("listen", ...)` rather than being flags `ling run` defines and interprets on its own.


[System] You are a coding assistant for the Ling programming language.

[User] What does `ling build --pack` do?

[Assistant] `--pack` is one of the real flags on `ling build <file.ling> [--out <path>] [--platform <target>] [--icon <path>] [--pack] [--aot]`, which compiles a `.ling` source file into a standalone executable/package. Combined with `--out <path>` for the output location, `--platform <target>` for the target platform, and `--icon <path>` for a custom icon, `--pack` is part of packaging the build into a distributable artifact.


[System] You are a coding assistant for the Ling programming language.

[User] What's the exact flag for AOT compilation with `ling build`?

[Assistant] `--aot`, e.g. `ling build app.ling --out app.exe --aot`. The verified flag set for `ling build <file.ling>` is `--out <path>`, `--platform <target>`, `--icon <path>`, `--pack`, and `--aot`.


[System] You are a coding assistant for the Ling programming language.

[User] What does the --interp flag on `ling run` actually do?

[Assistant] `--interp` forces the tree-walking interpreter backend instead of the default Cranelift JIT/AOT backend. You'd reach for it explicitly in a few real situations: (a) programs that use `http_serve` — web/long-running server programs are run under the interpreter in this ecosystem's real deployed sites, as noted in this very project's own app.ling header comment; (b) there's a known JIT struct-member-access bug, which makes `--interp` the safe choice for any struct-heavy program right now; and (c) the runtime also silently auto-falls-back to the interpreter if a JIT compile ever fails for a given program, so some people use `--interp` explicitly rather than relying on that implicit fallback.


[System] You are a coding assistant for the Ling programming language.

[User] Why does this project's app.ling get run with --interp instead of the default JIT?

[Assistant] Because it's a web server program using `http_serve` — this project's own app.ling header comment notes that web/long-running server programs are run under the interpreter in this ecosystem's real deployed sites. `--interp` forces the tree-walking interpreter instead of the default Cranelift JIT/AOT backend, which is the pattern used for `http_serve`-based programs.


[System] You are a coding assistant for the Ling programming language.

[User] My ling program has a lot of structs and I'm hitting weird bugs under the default backend. What should I try?

[Assistant] Run it with `--interp`. There's a known JIT struct-member-access bug in `ling`'s default Cranelift JIT/AOT backend, which makes `--interp` (the tree-walking interpreter) the safe/default choice for any struct-heavy program right now.


[System] You are a coding assistant for the Ling programming language.

[User] Does ling fall back automatically if the JIT can't compile my program, or do I have to pass --interp myself?

[Assistant] Both things are true and independent of each other. The runtime silently auto-falls-back to the interpreter if a JIT compile ever fails for a given program — you don't have to do anything for that case. But you can also pass `--interp` explicitly to force the tree-walking interpreter up front, instead of relying on that implicit fallback — for example if you already know your program hits the JIT struct-member-access bug or uses `http_serve`.


[System] You are a coding assistant for the Ling programming language.

[User] What's the default execution backend for `ling run`, and when does that change?

[Assistant] By default, `ling run` uses the Cranelift JIT/AOT backend. Passing `--interp` forces the tree-walking interpreter instead. You'd want `--interp` for: programs using `http_serve` (server/long-running programs are run under the interpreter in real deployed sites in this ecosystem), any struct-heavy program (there's a known JIT struct-member-access bug), or simply to be explicit rather than depend on the runtime's silent auto-fallback to the interpreter when a JIT compile fails.


[System] You are a coding assistant for the Ling programming language.

[User] Is there a performance reason to always use --interp?

[Assistant] No — the facts here are about correctness/compatibility, not performance. `--interp` forces the tree-walking interpreter instead of the default Cranelift JIT/AOT backend. The documented reasons to use it are: `http_serve`-based server programs are run under the interpreter in this ecosystem's real deployed sites, there's a known JIT struct-member-access bug that makes `--interp` the safe choice for struct-heavy programs, and the runtime already auto-falls-back to the interpreter on JIT compile failure, so `--interp` can just make that choice explicit.


[System] You are a coding assistant for the Ling programming language.

[User] If my ling program never touches structs and doesn't serve HTTP, do I still need --interp?

[Assistant] Based on the verified reasons for using `--interp` — `http_serve`/server programs, the JIT struct-member-access bug, and wanting to be explicit instead of relying on the silent JIT-failure fallback — a program with no structs and no `http_serve` usage doesn't hit any of those triggers, so there's no documented reason it would need `--interp`. It can use the default Cranelift JIT/AOT backend.


[System] You are a coding assistant for the Ling programming language.

[User] What happens if the JIT fails to compile my ling program and I didn't pass --interp?

[Assistant] The runtime silently auto-falls-back to the tree-walking interpreter if a JIT compile ever fails for a given program. `--interp` exists so you can make that same choice explicitly and deliberately, instead of relying on the implicit fallback behavior.


[System] You are a coding assistant for the Ling programming language.

[User] Explain the relationship between --interp and the JIT struct-member-access bug.

[Assistant] There's a known bug in the JIT backend around struct-member access. Because of it, `--interp` (which forces the tree-walking interpreter instead of the default Cranelift JIT/AOT backend) is currently the safe/default choice for any struct-heavy `.ling` program, to avoid tripping that bug.


[System] You are a coding assistant for the Ling programming language.

[User] Why does app.ling's header comment mention --interp?

[Assistant] Because app.ling is a web server program (it uses `http_serve`), and in this ecosystem's real deployed sites, web/long-running server programs are run under the interpreter — i.e. with `--interp`, which forces the tree-walking interpreter instead of the default Cranelift JIT/AOT backend. The header comment is documenting that operational choice.


[System] You are a coding assistant for the Ling programming language.

[User] Are --interp and the JIT auto-fallback the same mechanism?

[Assistant] No, they're related but distinct. `--interp` is an explicit CLI flag that forces the tree-walking interpreter up front. The auto-fallback is separate runtime behavior: if a JIT compile ever fails for a given program, the runtime silently falls back to the interpreter on its own, with no flag required. `--interp` can be used deliberately to get the same end state as that fallback, without depending on a JIT failure to trigger it.


[System] You are a coding assistant for the Ling programming language.

[User] How do I enable WASM support when building ling from source, e.g. `cargo build --features wasm`?

[Assistant] That won't work — there is no `wasm` Cargo feature for the `ling` crate. The real, exact feature list is `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, and `web` — no `wasm` entry among them. WASM support isn't a Cargo build-feature toggle at all; compiling a `.ling` program to run in a browser via WebAssembly is done through a separate tool, `lingc webgl <file.ling> [--out <dir>]`, which shells out to `wasm-pack` under the hood.


[System] You are a coding assistant for the Ling programming language.

[User] What are the real Cargo features for building ling.exe / lingc.exe from source?

[Assistant] Exactly these seven: `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, and `web`. There is no `wasm` feature in that list.


[System] You are a coding assistant for the Ling programming language.

[User] I want to compile my .ling program to run in a browser. What's the command?

[Assistant]
`lingc webgl myprogram.ling --out dist/`

That's a separate tool from `ling` itself: `lingc webgl <file.ling> [--out <dir>]` shells out to `wasm-pack` under the hood to produce a browser-runnable WebAssembly build. This is not controlled by any Cargo feature flag on the `ling` crate — there is no `wasm` Cargo feature.


[System] You are a coding assistant for the Ling programming language.

[User] Is WASM support toggled on/off via a Cargo feature flag like `llvm` or `gpu` are?

[Assistant] No — that's a plausible-sounding but incorrect assumption. The real Cargo feature list for the `ling` crate is exactly `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web` — there is no `wasm` feature at all. Actually building a `.ling` program to run in a browser via WebAssembly is done through a completely separate tool, `lingc webgl <file.ling> [--out <dir>]`, which shells out to `wasm-pack`, not through any `cargo build --features ...` flag on the `ling` crate itself.


[System] You are a coding assistant for the Ling programming language.

[User] What tool actually invokes wasm-pack in the ling toolchain?

[Assistant] `lingc webgl <file.ling> [--out <dir>]`. This is the real way to compile a `.ling` program for browser/WebAssembly execution; it shells out to `wasm-pack` under the hood. It's separate from the `ling` crate's Cargo feature flags, none of which is named `wasm`.


[System] You are a coding assistant for the Ling programming language.

[User] Does building ling.exe with `cargo build --release --features wasm` do anything?

[Assistant] No — `wasm` is not a valid feature name for the `ling` crate; that build would simply fail to resolve the feature (or be silently ignored depending on how it errors), since it doesn't exist. The real feature list is exactly `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`. Browser-targeted WASM output for a `.ling` program comes from a different tool entirely: `lingc webgl <file.ling> [--out <dir>]`, which shells out to `wasm-pack`.


[System] You are a coding assistant for the Ling programming language.

[User] Someone claimed WASM support is 'just another cargo feature flag' the same way `cuda` or `llm` are. Is that right?

[Assistant] No, that's a false belief worth correcting explicitly. `cuda` and `llm` (along with `llvm`, `gpu`, `vision`, `llm-cuda`, and `web`) are real Cargo features on the `ling` crate — that part of the pattern is right. But there is no `wasm` feature alongside them. WASM/browser output is produced by a wholly separate tool, `lingc webgl <file.ling> [--out <dir>]`, which shells out to `wasm-pack`, not by any Cargo feature flag on `ling` itself.


[System] You are a coding assistant for the Ling programming language.

[User] What's the difference between `ling run --wasm` and `lingc webgl`?

[Assistant] `--wasm` is one of the accepted flags on `ling run <file.ling> [--interp] [--wasm] [--web] [--device <n>] [-- <program args>]` — part of `ling`'s own hand-rolled CLI. `lingc webgl <file.ling> [--out <dir>]` is a different, separate tool whose job is specifically to produce a browser-runnable WebAssembly build by shelling out to `wasm-pack`. Don't conflate the two, and don't assume either one is controlled by a Cargo `wasm` feature — there isn't one; the real Cargo feature list for the `ling` crate is exactly `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`.


[System] You are a coding assistant for the Ling programming language.

[User] List every Cargo feature the ling crate actually supports.

[Assistant] `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web` — that's the complete, exact list. Notably absent: `wasm`. There is no Cargo feature that means 'compile ling itself with WASM support'.


[System] You are a coding assistant for the Ling programming language.

[User] How would I produce a WebAssembly build of a ling program if there's no wasm Cargo feature?

[Assistant] You wouldn't go through Cargo features at all for that. Use `lingc webgl <file.ling> [--out <dir>]` — a separate tool that shells out to `wasm-pack` to produce the browser-runnable WebAssembly build. The `ling` crate's own Cargo features (`llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`) are for building `ling.exe`/`lingc.exe` from source and have nothing to do with WASM output.


[System] You are a coding assistant for the Ling programming language.

[User] Can I build ling.exe with both `web` and `wasm` features together?

[Assistant] You can build with `web` (that's a real feature), but not with `wasm` — there is no such feature. The full, exact feature list for the `ling` crate is `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`. Something like `cargo build --release --features web` is valid; `--features web,wasm` is not, because `wasm` doesn't exist as a feature name.


[System] You are a coding assistant for the Ling programming language.

[User] Can I `use ling_ast` from my .ling application code?

[Assistant] No. The `ling-ast` crate (at `ling/crates/ling-ast` in the repo) is purely an internal library used by the parser -> MIR -> codegen pipeline inside the compiler/interpreter itself. It's not something an end-user `.ling` program ever references via `use`, and there's no legitimate scenario where application code should list `ling-ast` as a dependency or import it.


[System] You are a coding assistant for the Ling programming language.

[User] What's the difference between `ling ast` and the ling-ast crate?

[Assistant] They share the word "ast" but are otherwise unrelated in purpose. `ling ast <file.ling> [--technical] [--artwork] [--ling] [--all] [--out <path>]` is a user-facing CLI subcommand — a debugging/visualization tool that dumps a program's AST in different presentation modes. `ling-ast` (the crate at `ling/crates/ling-ast`) is a purely internal library used by the parser -> MIR -> codegen pipeline inside the compiler/interpreter itself; it's never something application code imports or depends on. Don't confuse the CLI command with the crate — it's a real naming-collision trap.


[System] You are a coding assistant for the Ling programming language.

[User] My program needs to inspect its own AST at runtime — should I add ling-ast as a dependency?

[Assistant] No. `ling-ast` (at `ling/crates/ling-ast`) is purely an internal library used inside the compiler/interpreter's own parser -> MIR -> codegen pipeline — it is never something an end-user `.ling` program references via `use`, and there's no scenario where application code should depend on it. If you want to look at a program's AST for debugging purposes, that's what the CLI subcommand `ling ast <file.ling>` is for (with `--technical`, `--artwork`, `--ling`, `--all`, `--out <path>` presentation modes) — a completely separate, user-facing tool that just happens to share the word "ast" in its name.


[System] You are a coding assistant for the Ling programming language.

[User] Is `ling-ast` a crate I'd add to my Cargo.toml, or a CLI command?

[Assistant] It's a crate — `ling-ast`, located at `ling/crates/ling-ast` — but it's an internal implementation detail of the compiler/interpreter's parser -> MIR -> codegen pipeline, not something you'd add as a dependency for application-level work. Don't confuse it with `ling ast`, which is a CLI subcommand (`ling ast <file.ling> [--technical] [--artwork] [--ling] [--all] [--out <path>]`) for dumping/visualizing a program's AST — a totally different, user-facing debugging tool that just happens to share the word "ast."


[System] You are a coding assistant for the Ling programming language.

[User] What does the ling-ast crate get used for?

[Assistant] It's purely an internal library used by the parser -> MIR -> codegen pipeline inside the compiler/interpreter itself. It lives at `ling/crates/ling-ast` in the repo. It is never something an end-user `.ling` program references via `use`, and application code should never list it as a dependency.


[System] You are a coding assistant for the Ling programming language.

[User] When someone says 'the ling AST tooling,' which of the two things — the crate or the command — are they usually referring to?

[Assistant] You have to disambiguate by context, because both exist and share the word "ast": `ling-ast` (the crate at `ling/crates/ling-ast`) is purely internal, used by the parser -> MIR -> codegen pipeline, and is never referenced by application code. `ling ast` (the CLI subcommand, `ling ast <file.ling> [--technical] [--artwork] [--ling] [--all] [--out <path>]`) is the user-facing debugging/visualization tool a developer would actually run from the command line. If someone's talking about running something from the terminal to inspect a program, they mean the `ling ast` command, not the `ling-ast` crate.


[System] You are a coding assistant for the Ling programming language.

[User] Where does the ling-ast crate live in the repo?

[Assistant] `ling/crates/ling-ast`. It's purely an internal library used by the parser -> MIR -> codegen pipeline inside the compiler/interpreter itself — not a public dependency for application `.ling` code, and not the same thing as the `ling ast` CLI subcommand.


[System] You are a coding assistant for the Ling programming language.

[User] Should I import ling-ast to write a linter for .ling source files?

[Assistant] No — `ling-ast` (at `ling/crates/ling-ast`) is purely an internal library used inside the compiler/interpreter's own parser -> MIR -> codegen pipeline. It's never something end-user code references via `use`, and there's no scenario where application code should treat it as a dependency. For inspecting a program's AST from outside the compiler, the user-facing tool is the CLI subcommand `ling ast <file.ling>` with its `--technical` / `--artwork` / `--ling` / `--all` / `--out <path>` presentation modes — a different thing entirely, despite the shared "ast" name.


[System] You are a coding assistant for the Ling programming language.

[User] Is `ling ast --all` part of the ling-ast crate's public API?

[Assistant] No — those are two separate things that happen to share a name. `ling ast --all` is a flag on the CLI subcommand `ling ast <file.ling> [--technical] [--artwork] [--ling] [--all] [--out <path>]`, a user-facing debugging/visualization tool. The `ling-ast` crate at `ling/crates/ling-ast` is an unrelated internal library used by the parser -> MIR -> codegen pipeline inside the compiler/interpreter; it has no public API meant for application code and is never imported via `use` by end-user `.ling` programs.


[System] You are a coding assistant for the Ling programming language.

[User] Explain the 'ast' naming collision in the ling project.

[Assistant] There are two distinct things in the `ling` ecosystem that both use the word "ast," and they're easy to mix up: (1) `ling-ast`, a crate at `ling/crates/ling-ast` that is purely an internal library used by the parser -> MIR -> codegen pipeline inside the compiler/interpreter itself — never referenced via `use` by application `.ling` code; and (2) `ling ast`, a CLI subcommand (`ling ast <file.ling> [--technical] [--artwork] [--ling] [--all] [--out <path>]`) that's a user-facing debugging/visualization tool for dumping a program's AST. They share a name but serve completely different audiences — one is compiler-internal plumbing, the other is a developer-facing CLI tool.


[System] You are a coding assistant for the Ling programming language.

[User] What's the build command for a full CUDA-accelerated, in-process-LLM web server build of ling?

[Assistant]
`cargo build --release --features web,llm,llm-cuda`

That combination — `web`, `llm`, and `llm-cuda` — is exactly what's needed for a full CUDA-accelerated in-process-LLM web server build.


[System] You are a coding assistant for the Ling programming language.

[User] I'm hitting a nightly toolchain ICE (internal compiler error) building ling with `cargo build --release --features web,llm,llm-cuda`. What should I do?

[Assistant] Switch to the stable toolchain rather than modifying the build config: `cargo +stable build --release --features web,llm,llm-cuda`. This project hit exactly that nightly ICE and resolved it by switching toolchains. Avoid touching the shared root `[profile.release]` settings (like `lto` or `codegen-units`) to work around it — that profile is shared with other production sites that reuse the same workspace Cargo.toml, so changing it for one build risks breaking builds elsewhere.


[System] You are a coding assistant for the Ling programming language.

[User] Is it safe to tweak `[profile.release]` (lto, codegen-units) in the root Cargo.toml to fix a build issue?

[Assistant] Treat that as risky and avoid it if you can. The root `[profile.release]` (covering things like `lto` and `codegen-units`) is shared, and other production sites reuse the same workspace Cargo.toml — so a change there for one build's sake can silently affect unrelated builds. For a nightly-toolchain-only ICE specifically, the safe fix is switching toolchains (e.g. `cargo +stable build --release --features web,llm,llm-cuda`), not touching the shared release profile.


[System] You are a coding assistant for the Ling programming language.

[User] What features do I need to build lingc.exe with LLVM and GPU vision support?

[Assistant] Based on the real Cargo feature list (`llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`), you'd combine the relevant ones, e.g. `cargo build --release --features llvm,gpu,vision`.


[System] You are a coding assistant for the Ling programming language.

[User] Why did this project switch to `cargo +stable` for its release build instead of using the default nightly toolchain?

[Assistant] Because building with `cargo build --release --features web,llm,llm-cuda` on nightly triggered a toolchain ICE (internal compiler error). The fix used was switching toolchains — `cargo +stable build --release --features web,llm,llm-cuda` — rather than modifying the shared root `[profile.release]` settings (lto/codegen-units), which would be risky since other production sites reuse the same workspace Cargo.toml.


[System] You are a coding assistant for the Ling programming language.

[User] What's the risk in changing lto or codegen-units in the workspace Cargo.toml to work around a compiler bug?

[Assistant] The root `[profile.release]` block is shared across the whole workspace, and other production sites reuse that same Cargo.toml — so changing `lto` or `codegen-units` there to fix one problem can have unintended effects on builds for other sites. For a nightly-only ICE specifically, the safer, verified fix is switching toolchains (`cargo +stable build --release --features ...`) rather than touching that shared profile.


[System] You are a coding assistant for the Ling programming language.

[User] Give me the exact cargo invocation for building ling with CUDA-backed LLM support behind a web server, on stable Rust.

[Assistant]
`cargo +stable build --release --features web,llm,llm-cuda`

This is the stable-toolchain variant of the full CUDA-accelerated in-process-LLM web server build; it's what this project switched to after a nightly toolchain ICE forced the move off nightly, using the same `web,llm,llm-cuda` feature combination.


[System] You are a coding assistant for the Ling programming language.

[User] Do I need the `gpu` feature in addition to `llm-cuda` for the CUDA LLM web server build?

[Assistant] Based on the verified command for that build, no — the exact combination given is `--features web,llm,llm-cuda`. `gpu` is a separate, real feature in the crate's feature list (`llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`), but it's not part of the documented full CUDA-accelerated in-process-LLM web server build command.


[System] You are a coding assistant for the Ling programming language.

[User] What toolchain issue has this project actually hit when building ling from source?

[Assistant] A nightly Rust toolchain ICE (internal compiler error) when building with `cargo build --release --features web,llm,llm-cuda`. The fix was switching to the stable toolchain: `cargo +stable build --release --features web,llm,llm-cuda`, rather than modifying the shared `[profile.release]` settings in the root Cargo.toml.


[System] You are a coding assistant for the Ling programming language.

[User] If cargo build --release with certain features ICEs on nightly, is the right move to disable LTO in the profile?

[Assistant] No — that's the risky move, not the recommended one. The root `[profile.release]` (including `lto` and `codegen-units`) is shared, and other production sites reuse the same workspace Cargo.toml, so editing it to dodge a nightly-only ICE could break other builds. The safe, verified fix for a nightly-only ICE is switching toolchains — e.g. `cargo +stable build --release --features web,llm,llm-cuda` — not touching the shared release profile.


[System] You are a coding assistant for the Ling programming language.

[User] Summarize how to build a production ling.exe with in-process LLM + CUDA + web server support, including the toolchain caveat.

[Assistant] Use `cargo build --release --features web,llm,llm-cuda` for the full CUDA-accelerated in-process-LLM web server build. If you hit a nightly toolchain ICE with that command (as this project did), switch to the stable toolchain instead of editing the build config: `cargo +stable build --release --features web,llm,llm-cuda`. Don't try to fix a nightly-only ICE by modifying the shared root `[profile.release]` (`lto`, `codegen-units`) — that profile is shared with other production sites that reuse the same workspace Cargo.toml, so changing it is risky and switching toolchains is the safer fix.


[System] You are a coding assistant for the Ling programming language.

[User] Quick sanity check: does `ling` have a --wasm Cargo feature, a --port CLI flag on `ling run`, and a clap-based main.rs? Correct anything wrong.

[Assistant]
All three of those are wrong as stated:

1. There's no `wasm` Cargo feature for the `ling` crate. The real feature list is exactly `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`. Browser WASM builds go through the separate `lingc webgl <file.ling> [--out <dir>]` tool instead.
2. `ling run` doesn't itself define/parse a `--port` flag. `--port <n>` (like `--listen <addr>`) is consumed by the running `.ling` program's own `cli_arg("port", ...)` call, not by `ling`'s CLI parser.
3. `main.rs` is not clap-based — `ling`'s real argument parsing is hand-rolled directly in `src/main.rs`. There is a clap-derive-style `src/cli.rs`, but it's confirmed dead code, never wired into `main()`.


[System] You are a coding assistant for the Ling programming language.

[User] List things that DON'T exist in ling's real CLI/build system that people might assume do.

[Assistant] A few concrete non-existent things worth calling out: there is no `wasm` Cargo feature on the `ling` crate (the real list is `llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`); `ling run` has no built-in `--port`/`--listen` flags of its own (those are read by the running `.ling` program via `cli_arg()`); and the CLI is not clap-based at runtime — `src/cli.rs`'s clap-derive structs exist in the repo but are dead code, never wired into `main()`. The actual CLI is hand-rolled parsing in `src/main.rs`.


[System] You are a coding assistant for the Ling programming language.

[User] What's the full flag set for `ling ast`, and is it something a running .ling program can call?

[Assistant] The flags are `--technical`, `--artwork`, `--ling`, `--all`, and `--out <path>`, used as `ling ast <file.ling> [--technical] [--artwork] [--ling] [--all] [--out <path>]`. It's purely a CLI-level debugging/visualization tool for dumping the parser's AST output in different presentation modes — a `.ling` program never imports or calls it at runtime. (It's also unrelated to the internal `ling-ast` crate at `ling/crates/ling-ast`, despite the shared name.)


[System] You are a coding assistant for the Ling programming language.

[User] Does the `web` Cargo feature have anything to do with the `--web` flag on `ling run`?

[Assistant] They're both real and both use the word "web," but they operate at different layers: `web` is one of the seven real Cargo features (`llvm`, `gpu`, `cuda`, `vision`, `llm`, `llm-cuda`, `web`) used when building `ling.exe`/`lingc.exe` from source. `--web` is a flag accepted by the already-built `ling run <file.ling> [--interp] [--wasm] [--web] [--device <n>] [-- <program args>]` command at runtime. Neither of these is the same as WASM/browser support, which is handled by the separate `lingc webgl` tool, not by a Cargo feature or by `ling run --web`.