Kern for Visual Studio Code

Language support for Kern: syntax highlighting, the real compiler's diagnostics as you type, quick fixes, completion with auto-import, hover docs, signature help, go to definition, an outline, and Run / Check / Build / Test commands.

Everything that needs the compiler calls the kern binary you already have, so what the editor reports is exactly what kern check reports.

Features

Highlighting. A TextMate grammar for the whole language: imports, functions and lambdas, structs, unions and variants, traits and impls, annotations, ${...} interpolation, triple-quoted strings, ## doc comments (with inline code and error codes), and tab indentation flagged as an error. Kern code blocks in Markdown are highlighted too.

Diagnostics from kern check, on open, on save and while you type (debounced).

• Unsaved changes are checked through a hidden copy next to the file, so from ./lib import ... resolves exactly as it does on disk. The copy is deleted after every check and hidden from the Explorer.
• Parse errors are placed where they happen (kern reports them at line 0 with the position in the message).
• Errors inside an imported module are shown on the import line, linked to the real location.
• Misleading hints are rewritten. For an un-imported sqrt, kern says Did you mean 'sqrt'?; the extension says 'sqrt' is defined in std.math; it needs an import. For E0327, kern suggests from lib.kern import x, which does not parse; the extension suggests from ./lib import x.

Quick fixes (Ctrl+. / Cmd+.)

• Import an undefined name from the standard library or a local module.
• Rename to the nearest name the program can use, importing it when needed.
• E0327: import the name from the module that declares it.
• E0202: make the function pub in its module.
• Explain any error code.

Fix all (Kern: Fix All Unambiguous Spelling Errors, or source.fixAll.kern in editor.codeActionsOnSave). It applies a kern fix rename only when the new name is the unique nearest name the program could use. kern fix --dry-run also proposes renames that are no-ops (sqrt to sqrt), capability-gated (cnt to cwd, which then fails with E0404) or plausible but wrong (flor to float when floor from std.math was meant); those stay as quick fixes for you to choose.

Completion

• Locals and parameters, with their inferred types.
• After .: fields, impl methods, functions that take the value as their first argument, and builtins.
• After a module alias (json., std.math.): that module's exports.
• After from / import: standard library and local module names; inside an import list, the module's exports.
• Types in type positions, annotations after @, keywords.
• Auto-import: standard library functions and types that are not imported yet, with the import added for you.
• Capability-gated builtins (callable only inside std.cap_*) are never offered.

Hover. Signatures, doc comments, struct fields, inferred variable types, module docs, builtin docs (naming the std module to use instead of a capability-gated builtin), and error codes with an Explain link.

Signature help with the active parameter, including named arguments (User(name: ...)).

Go to definition for variables, functions, types, fields, methods and modules, across files and into the stdlib.

Outline and workspace symbols (Ctrl+T / Cmd+T).

Run, Check, Build, Test. A code lens above fn main, a Run button in the editor title bar, and commands. Test files (*_test.kern, test_*.kern, or anything in a test/ or tests/ folder of the workspace) get Run test first. Commands are typed into a terminal named Kern, quoted for your default shell (POSIX shells, PowerShell or cmd.exe; under Git Bash on Windows, paths are written C:/like/this). Kern: Show Capability Graph runs kern audit-caps.

Explain error code shows kern explain as a Markdown preview.

Snippets for common constructs (main, fn, fnr, type, union, impl, match, matchr, select, for, fori and more), each checked to parse with kern 1.0.1.

Requirements

The Kern compiler. The extension looks for it in the kern.path setting, then on PATH, then in ~/.local/bin, ~/.kern/bin, /opt/homebrew/bin, /usr/local/bin and /usr/bin. The standard library is found next to the compiler, or through kern.stdlibPath or the KERN_STDLIB environment variable.

Without the compiler, highlighting, completion, hover and navigation still work from a bundled index of the kern 1.0.1 standard library; diagnostics, quick fixes from the compiler and the Run commands need kern.

Tested with kern 1.0.1 and VS Code 1.143 (works with VS Code 1.85 and later).

In Restricted Mode only the declarative parts work (highlighting, snippets, brackets and indentation): the rest runs or reads the compiler, and a workspace setting could point kern.path at any program, so it waits until you trust the folder.

Settings

Kern files default to 4-space indentation, trimmed trailing whitespace and a final newline.

No formatter, on purpose

kern fmt in kern 1.0.1 drops comments and rewrites the contents of strings, so the extension does not register it as a formatter.

Known limitations

• Types are inferred by the extension, not by the compiler. Common cases work (constructors, fields, method chains, generics, loops, operators); when a receiver's type cannot be worked out, member completion shows nothing rather than guessing.
• The copy for unsaved changes (_kern_vscode_name.kern) is written next to your file because kern check only accepts a path. It exists only while a check runs; add _kern_vscode_*.kern to .gitignore if your git tooling notices it. If the folder is read-only, a temporary-directory copy is used, and local imports in unsaved changes report E0600 until you save.

Development

npm install
npm run compile
npm test          # unit tests, grammar tests, then integration tests in VS Code
npm run gen       # regenerate data/ from the installed kern (builtins, error codes, stdlib index)
npm run package   # build the .vsix

The integration tests use your installed VS Code (or $VSCODE_PATH) with a throwaway profile and a temporary copy of test/fixtures/ws, and need kern on the machine.

License

EUPL-1.2, the same as Kern: the files in data/ are generated from Kern's own sources and documentation.