Jump to declaration for nixos module config attributes

[Atemu]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

nixd is able to jump to NixOS option declarations from the point they're set but not the points where their value is read using the config argument.

Describe the solution you'd like
A clear and concise description of what you want to happen.

It'd be great if nixd could also jump to option declarations from config.option.name.here

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

-

Additional context
Add any other context or screenshots about the feature request here.

It's common for config attributes to be put into another variable via let:

{ config, ... }:

let
  cfg = config.foo.bar;
in
{
  bar.foo = cfg.baz;
}

nixd should be able to resolve this redirection and jump to the declaration of options.foo.bar.baz when attempting to jump to the declaration of cfg.baz.

[inclyc]

Generally I don't like to add more heuristics. I'd expect a mathmatical deducing model to address all these stuff.

Much similar problem also reported in #600, where we cannot deal with nixos options declared inside config.

I think finally a type system should be added in Nix language, we can do this in lsp first (like python's type annotation).

@luochen1990 do you have some ideas?

[luochen1990]

A type system in lsp is cool, but there is indeed two different mechanism we need to have if we choose to implement all these in lsp instead of a new language -- the type system for nixos modules, and the type system for normal nix codes. They are very different but intuitively can be fused into a single one, but I don't know how to fuse them yet

[Atemu]

I don't think proper typing is going to happen in Nix any time soon. If work were to start now, I'd expect it to be usable no sooner than a decade later.

I also don't understand how a type system would be relevant here as this should be able to use a similar code-path to the current jump to option declaration; regardless of its type.