Typed rules

[vidit-od]

This PR introduces typed inputs for HLS/ghcide rules.

HLS already associates every rule key with its result through RuleResult, but all rules previously accepted the same input type: NormalizedFilePath. Theis PR adds an open type family that associates each rule with the kind of input it supports:

type family RuleInput k

type instance RuleInput TypeCheck = ProjectHaskellInput
type instance RuleResult TypeCheck = TcModuleResult

Rule inputs are now part of the rule's contract, just like rule results.

Why this is needed

A raw NormalizedFilePath does not tell us what a path actually represent. These distinctions matter. For example, TypeCheck and GhcSession require a project component and session, while file-content rules can work on many file
types. Typed inputs make these assumptions explicit, reject incorrect rule/input pairings earlier, and provide the foundation needed to support dependency sources without treating them as project modules.

How it works

The new Development.IDE.Core.RuleInput module defines this input hierarchy:

SomeInput
|-- NoInput
`-- SomeFileInput
    |-- SomeHaskellInput
    |   |-- ProjectHaskellInput
    |   `-- NonProjectHaskellInput
    |-- CabalInput
    `-- arbitrary NormalizedFilePath

Internally, Shake still needs one heterogeneous key representation. SomeInput
therefore existentially stores typed inputs inside Q, while InputFingerprint
provides consistent equality and hashing.

[wz1000]

Broadly looks good, some inputs need to be tightened up

[fendor]

Thanks, this looks very nice! This is a nitpick review, so it is the intention to be done after the review is addressed. I have reviewed the ghcide changes, will review plugins soon.

Further, we agreed the following documentation is still missing and will be added:

    * What are the existing rules?
    * What is RuleInput?
    * Why do we have RuleInput
    * What is the design of RuleInput
        Note [Hierarchical Inputs]
        Note [RuleInput]
        
        Reference these notes from various type classes and RuleInput type
    * Helper functions need documentation

[fendor]

We might want to demote this to Debug. IIRC, a warning is displayed in the editor, but these errors will be perfectly sensible in the future, right?

@wz1000 opinions?

[fendor]

Some more comments :)

[fendor]

We shouldn't do anything here, rather log this case.

[fendor]

@wz1000 What should we do in this case? Call setSomethingModified for completeness? We need to add it to the set of files of interest, but it might not need to record that it isn't the first time this non project haskell file was opened, right? 🤔

[wz1000]

setSomethingModified is not correct here, that will trash the entire session. I think setFileModified should accept SomeHaskellInput instead of ProjectHaskellInput

It should always restart with the new VFS and dirty the file’s GetModificationTime, then run typecheckParents only in the SomeProjectHaskellInput branch

[fendor]

Same here

[wz1000]

plugins and input types broadly look correct. I need to do another more careful pass though.

[wz1000]

setSomethingModified is not correct here, that will trash the entire session. I think setFileModified should accept SomeHaskellInput instead of ProjectHaskellInput

It should always restart with the new VFS and dirty the file’s GetModificationTime, then run typecheckParents only in the SomeProjectHaskellInput branch