Skip to content

Tooling and Linting

Accepted

Accepted for the V1 compiler, formatter, lint, and convention boundary; first-class lint configuration, suppression, autofixes, project policy, and LSP are deferred.

Tooling is part of the language design, not an afterthought. Features that cannot be inspected by compiler tools or editors should be treated skeptically.

The reference compiler command-line tool is named cata. Command examples for reference compiler behavior should use cata ... spelling.

Formatter

The compiler should ship a canonical formatter for .ct source. Formatting owns source layout, not naming or semantic convention rewrites.

See Formatter for the compiler-side formatter contract and Code Style for the canonical source style.

Compiler-Integrated Linting

The compiler ecosystem should eventually support lints and autofixes for conventions and API clarity. V1 records lint identities and advisory suggested policy, but does not require the full lint engine.

See Lint Catalog for current lint identities and First-Class Linting for the deferred lint-engine model.

Examples:

  • public APIs with inferred signatures
  • incorrect init / create / dispose / destroy conventions
  • ownership or resource mistakes
  • unused or misleading APIs
  • realtime functions using forbidden capabilities or APIs

Compiler vs Lint Boundary

Catalyst separates:

  • hard compiler error
  • warning
  • lint
  • convention only

The V1 rule is conservative: enforce phase contracts and deterministic behavior as compiler errors; use the formatter for canonical source layout; leave naming, API conventions, cleanup conventions, and project policy as lint or convention unless a feature page explicitly makes them semantic.

Warnings are non-fatal compiler diagnostics only when an owning compiler phase, tool, or comptime call to Compiler.warn explicitly produces one. Suspicious but valid source patterns should be cataloged as lints instead of becoming ad hoc compiler warnings.

Documented conventions are not compiler findings unless the relevant page gives them a stable lint identity or semantic rule. Lints have advisory severities in the catalog; those severities do not define source validity.

Resource ownership follows the same boundary. Copy prohibition and explicit move state are hard semantic rules; generated cleanup for compiler-owned hidden temporaries is lowering semantics; ordinary user-visible cleanup obligations are explicit source conventions and optional lint candidates. The detailed resource lint candidates are documented in Ownership and Resources and named in Lint Catalog.

V1 does not define lint configuration, lint suppression, lint-as-error profiles, autofix representation, generated-code policy, or LSP/editor reporting. Those behaviors are deferred to First-Class Linting.