Autocompletion from a contract computed by merging

[thufschmitt]

Is your feature request related to a problem? Please describe.

The Nickel lsp currently provides completion for field names when writing a record with a record contract. For instance:

{
  ab<CURSOR>
} | ({ abcde | Number, fghij | Number })

will offer abcde as completion.

However this only works if the contract is a record literal. For instance, there will be no completion for the snippet below:

{
  ab<CURSOR>
} | ({ abcde | Number } & { fghij | Number })

Describe the solution you'd like

Allowing any kind of computation in the LSP is probably not a good idea, but ome heuristic to allow completion with contracts which are marginally more complex than a record literal would be very useful. In particular plain merging could be allowed here.

Describe alternatives you've considered

Not merging contracts. But that would make my life very painful. Or living without completion, but that would be sad too.

Additional context

https://github.com/nickel-lang/nickel-nix is making a heavy usage of merged contracts (all the builders and shells are defined with some variation of Derivation & { some_extra_arg | Number, some_other_extra_arg | String }), so this would be very valuable

[thufschmitt]

A variation of the above (let me know if you think it deserves its own issue) is completion based on field names for merged records. For instance

{
  abcde | Number,
  ab<CURSOR>
}

offers a completion for abcde, but not

{
  abcde | Number,
} & {
  ab<CURSOR>
}

[yannham]

Related: #1477. I think the current state of the semantics doesn't address this, and the semantics of completion for merging should be quite natural (probably completion_items(a & b) = completion_items(a) U completion_items(b))

[yannham]

My bad, it did address it already, I just hadn't seen the change.