Files
Nim/compiler
araq c01e58c146 IC: eight correctness fixes found by differential testing against nim c
Grinding a small figdraw-based program under `nim ic` and diffing its output
against the classic backend surfaced eight bugs, four of which silently produced
a wrong binary rather than an error.

Frontend / build graph (`deps.nim`):

* Dead `when`-guarded imports were compiled anyway. `when someStrdefine == "x":
  import y` is `cvUnknown` to the scanner, which conservatively keeps the edge —
  right for an edge, but it also gave `y` its own `nim m` rule, so a build died
  on a package the user never installed because they never selected that backend.
  Track which edges are speculative and drop a speculative subtree that cannot
  compile; if the guard was in fact live, the discovery fixpoint puts the node
  back with the honest `cannot open file`.
* Deleting a still-imported module went unnoticed: no mtime moves, so nothing
  re-fires and `nim ic` relinked a stale binary while `nim c` reported `cannot
  open file`. Report an unresolvable import from a non-speculatively reached
  module during the graph scan.
* Macro-generated imports were discovered once and then forgotten. Discovery
  only ran after a failure and the graph is re-derived statically every run, so
  on a warm build the discovered module had no rules at all and editing it
  changed nothing. Seed the graph from the `.s.deps` sidecars up front.
* Config changes invalidated nothing. nifmake decides staleness from file mtimes
  and never looks at a rule's command line, so `-d:foo=bar` / `--mm:` / `--threads:`
  regenerated the build file with the new switches and re-fired zero rules.
  Reify the configuration as a file and make it an input of every rule.
* Command-line switches never reached the children: they replay the project's
  config files, never the driver's argv, so `nim ic --opt:speed` produced a
  byte-identical debug binary (likewise `--panics`, `--experimental`, `--passC`).
  Forward the driver's switches, minus the ones that must differ per child.

Artifacts and codegen:

* A failed `nim m` still wrote its `.s.bif` and cookies, so nifmake saw the rule
  as satisfied on the next run: `nim ic` then reported success for a program that
  does not compile, and generated code from error-bearing AST (or hit an internal
  error in `ccgexprs`). Never persist an artifact when `errorCounter > 0`.
* Top-level destructors were never injected. `sfInjectDestructors` lives on the
  module symbol, which `moduleFromNifFile` rebuilds from scratch, so
  `genTopLevelStmt` skipped `injectDestructorCalls` entirely: a module-level
  `block: let h = openHandle()` never ran `=destroy`. Persist the flag as a
  `(modflags)` record. `injectdestructors` also has to tolerate the
  `nkReplayAction` entries the loader prepends to `topLevel`.
* `nfFirstWrite` / `nfLastRead` were dropped by the serializer. A sym node is
  written as a bare NIF `SymUse` token, which has nowhere to put node flags, so
  the frontend's move analysis never reached the backend: EVERY first assignment
  to a destructor-bearing local compiled as `=sink`, i.e. `=destroy` on
  still-zeroed memory followed by a copy, and no read was ever a move. Wrap a sym
  use in `(nflags ...)` when it carries persistent node flags.

`icFormatVersion` 34 -> 35 for the two new NIF records.

Validation: `koch bootic` reaches its byte-identical fixed point; two clean-cache
builds from the same compiler are identical; testament `arc`, `destructor`,
`macros`, `template`, `iter`, `closure`, `ccg`, `codegen`, `types` and `effects`
pass, and `generics`, `ic` and `stdlib` show exactly the pre-existing failures.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 19:24:08 +02:00
..
2026-07-03 15:52:41 +02:00
2026-06-11 14:10:42 +02:00
2026-02-10 13:21:35 +01:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-06-25 23:20:34 +02:00
2026-06-14 22:35:06 +02:00
2026-06-14 22:35:06 +02:00
2017-01-07 22:35:09 +01:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2025-12-11 18:22:38 +01:00
2025-12-11 18:22:38 +01:00
2026-07-03 15:52:41 +02:00
2026-07-04 10:13:39 +02:00
2025-11-25 12:49:23 +01:00
2026-08-17 15:02:49 +02:00
2024-12-27 19:42:18 +01:00
2026-06-14 22:35:06 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2025-12-11 18:22:38 +01:00
2026-04-02 07:19:43 +02:00
2026-06-14 22:35:06 +02:00
2026-06-25 23:20:34 +02:00
2021-01-12 09:36:51 +01:00
2026-08-17 15:02:49 +02:00
2026-01-09 13:10:04 +01:00
2026-06-14 22:35:06 +02:00
2026-08-17 15:02:49 +02:00
2026-07-03 15:52:41 +02:00
2026-07-03 15:52:41 +02:00
2026-07-08 15:39:40 +02:00
2026-06-24 21:58:51 +02:00
2025-12-11 18:22:38 +01:00
2026-08-17 15:02:49 +02:00
2026-06-14 22:35:06 +02:00
2026-08-17 15:02:49 +02:00
2026-02-10 13:21:35 +01:00
2026-08-17 15:02:49 +02:00
2023-07-02 22:36:05 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-11 22:27:49 +02:00
2025-12-11 18:22:38 +01:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2025-12-11 18:22:38 +01:00
2026-08-17 15:02:49 +02:00
2025-12-11 18:22:38 +01:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-06-24 21:58:51 +02:00
2026-06-25 23:20:34 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2026-08-17 15:02:49 +02:00
2023-12-25 07:12:54 +01:00

Nim Compiler

  • This directory contains the Nim compiler written in Nim.
  • Note that this code has been translated from a bootstrapping version written in Pascal.
  • So the code is not a poster child of good Nim code.

See Internals of the Nim Compiler for more information.