Hlint issue with QuantifiedConstraints

[georgefst]

Originally reported on the hlint repo.

Using a quantified constraint results in an 'illegal class assertion error' coming from the hlint parser. But the same version of hlint (2.2.10), run as a standalone executable, parses the file with no issues.

[jneira]

Hi @georgefst, did you need to change hlint.yaml to get standalone hlint work, or it worked with no config change?

[georgefst]

Worked with no config change.

Does hie specify its own internal hlint.yaml in lieu of a user one? Or read flags from hie-bios for example? Because the nature of this bug seems to suggest that it isn't using the same default settings as standalone hlint.

[jneira]

Your guess is right afaik, hie (in fact hlint used as a library) is not using the exactly same way to discover hie.yaml than hlint executable. Not sure what are the locations, maybe @Avi-D-coder can remember better: but you can try to create a dir named data where you have your hie executable and put in that datasubdir your hlint.yaml.

[Avi-D-coder]

I have yet to look into this, but I would try searching your home directory for hlint.yaml not .hlint.yaml. hlint defaults to using a baked in copy and any adjustments to the default should go in .hlint.yamls, so your issue should be fixed if you delete all hlint.yamls.

[Avi-D-coder]

@jneira I was not aware that custom hlint data dir logic remained, we should tear it out to match the hlint executable.

[georgefst]

I can't check this until I'm back in work tomorrow, but I'm pretty sure a ran find ~ -name hlint.yaml and it showed just the one in ~/data, which was empty.

[Avi-D-coder]

Your going to want to delete ~/data. There has to be an old hlint.yaml on your system for hie to use it instead of the up to date copy baked into the binary. How is hie installed? which hie & stack | cabal | nix | arch?

[jneira]

@jneira I was not aware that custom hlint data dir logic remained, we should tear it out to match the hlint executable.

I am not sure about that, i only hope that hie will search for at least one location out the embed file!

[georgefst]

Ok, I've purged all hlint.yaml and .hlint.yaml files from my system, and still have the issue.

Can anyone else confirm whether they get this behaviour? I'm using plenty of other extensions and this is the only problematic one here. Probably no coincidence that it's a fairly new one.

How is hie installed?

Cloned from github at some point in the past week. Then something like cabal v2-install --installdir=$HOME/bin --install-method=copy

[Avi-D-coder]

What GHC version are you using?

[georgefst]

What GHC version are you using?

8.6.5 (installed via ghcup on Ubuntu 16.04).

[ndmitchell]

I note that haskell-src-exts 1.22 introduces support for QuantifiedConstraints. HLint 2.2.10 allows >=1.21 && <1.24, so it's entirely possible that HLint standalone is using a newer version of haskell-src-exts but hie is using an older one. That would account for the behaviour you are seeing.

[georgefst]

Aha, thanks @ndmitchell.

Building with --constraint="haskell-src-exts >= 1.22" --allow-newer=haskell-src-exts did the trick.

[jneira]

We could close it ensuring hie use haskell-src-exts 1.22

[fendor]

I am in favour of updating the dependencies! Monthly release ahead, anyways ;D

[jneira]

Ok, so we need use haskell-src-exts >= 1.22 but it turns out that it is not straightforward:

• Actual release version of hsimport it out of bounds: haskell-src-exts (>=1.18.0 && <1.22)
• Same for floskell

So we should ask for new hackage releases and use git submodules or source-repository-package for cabal or the equivalent for stack (temporary). I've tried adding:

source-repository-package
    type: git
    location: https://github.com/dan-t/hsimport
    tag: 9528ba4aac4cd70b29cfdda166e94923b61ff23b

and the project builds with cabal using ghc-8.4.4 and ghc-8.6.5 So we can, after asking for new releases:

• Simply wait for them
• Change all cabal/stack config files to use master (running test suites)
• Create submodules for hsimport and floskell

Thoughts @fendor @alanz?

EDIT: Only hsimport need to be included as source-repository-package so the option of change config files seems to be more feasible

[jneira]

I am going forward adding hsimport to stack and cabal config files: https://github.com/haskell/haskell-ide-engine/compare/master...jneira:hask-src-exts-1.22?expand=1 Currently running it in azure: https://dev.azure.com/jneira/haskell-ide-engine/_build/results?buildId=667&view=results

[fendor]

cant we also overwrite dependency constraints of hsimport in stack.yaml and cabal.project? In my local project, bumping the constraitns to < 1.24 works. Then we dont have to wait for a release and lines to delete and update.

[jneira]

It would be better for cabal but i think it is better to not add allow-newer: true to all stack.yaml's