Type system and attributes analysis about nil HOT 5 OPEN

The initial implementation of type system is included in 2022-11-07.
Currently type inference is done in individual files and have no information input. Polymorphism is also not implemented yet. But it already improved the completion experience a lot.

from nil.

Since 2 is easy and mostly works, if there are cases where it's not sufficient a way to annotate (a comment after the arg?) the correct type could be useful.

I like the idea of for flakes being able to evaluate the flake and its outputs and record the types things had during that evaluation so they're guaranteed to be right. Could even record multiple types when something has different types depending on where it's called. That also sounds really hard.

from nil.

An idea I have about this issue is to possibly use type annotations or otherwise say where the things going into some lambda come from, since it will be different in NixOS modules (regrettably).

Like:

# @type callPackage
{ hello, stdenv }: ....

from nil.

Type schema of flake.nix is implemented since d044c9c. Completion of inputs and known input fields like outPath, modifiedDate work now. But since we don't evaluate flakes yet, their real output cannot be completed.

Flake output fields also work, but only when a direct Attrset literal is given in the output. If you use other wrappers like flake-utils, it will not work currently.

from nil.

Ideally this could be extended to even provide diagnostics.

I thought, one could start with typing all builtins and maybe nixpkgs.lib and then inferring every time there is a guaranteed type conflict, i.e. when someone swaps the arguments of map.

from nil.