- Cabal/stack plugin: Live at spinda/liquidhaskell-cabal with a demo at spinda/liquidhaskell-cabal-demo.
- Publish to Hackage: All ready on my end, but I’m currently blocked awaiting a new release of LiquidHaskell to Hackage containing the tweaks I had to make to the source to get this to work.
- Improve LH’s CLI output: Right now LiquidHaskell’s output is pretty noisy, and that doesn’t fit in well with the rest of the Cabal output. I’ll work on improving this when I get a chance.
- Improve multi-target support: The Cabal plugin uses LiquidHaskell’s existing support for checking the correctness of multiple modules, passing it all the source files in the project at once. At the moment the implementation of this is rather naive, rerunning the entire pipeline for each module and doing more recompiles than it needs to for each module. As part of the ApiAnnotations work (see below) I’m going to change this so we check all target modules in a single pass instead.
- Ambiguity error in Bare: Really simple, there’s a spot where we’re resolving names and if there’s more than one possible match we pick the first one. Instead we should be throwing an error about ambiguity. See issue #525.
- ApiAnnotations: Have LiquidHaskell extract comments via GHC’s ApiAnnotations interface instead of parsing them out ourselves; see issue #617. At the moment LH does a recursive parsing thing to identify all the modules and source files it needs to process, parses in all the specifications, and then loads the modules into GHC. I’ll need to change this so that the parsing happens after each module is loaded into GHC in order to use the ApiAnnotations interface. While I’m making this change I can improve our support for multiple target modules. This will also lay some groundwork for the .lqhi changes (see below).
- Package DB version check: Issue #612 seems to have caused by a case where the version of GHC LiquidHaskell was compiled with was trying to load in an interface built by an older version of GHC. To guard against this I’ll add a check to make sure that the GHC version in the environment’s package database matches what we expect.
- .lqhi intermediate files: In processing imported modules, LiquidHaskell needs access to information that is only available when GHC has just finished compiling that module. As a result, for each target module, it currently recompiles all the recursive dependencies of that modules every run to get at that information. In my GSoC ‘15 work I implemented a feature where this information is saved to intermediate .lqhi files after each modules is processed and quickly loaded back in when needed in a future run. This is currently stuck on my outdate fork, however, so I’ll need to port it over to the current version of the codebase.
- Get it working with files first: The first iteration will create the .lqhi files and load them back in when they’re needed. This will require that LH’s specification-extraction pipeline process each module independently instead of smooshing them together and extracting everything all at once. The ApiAnnotations work will accomplish part of this.
- Move to GHC Annotations: Once the GHC plugin is in (see below), transition this to store the intermediate information in GHC Annotations, inside the Haskell .hi files, instead.
- GHC plugin: Another thing I did in my GSoC fork was make LiquidHaskell work as a GHC plugin instead of a standalone executable. I’d like to get that finally ported over and merged into
master, as an alternative entry point instead of replacing the CLI interface altogether. I already have a work-in-progress copy of this that’s functioning in some cases, but it still has a ways to go (and needs the .lqhi stuff to be implemented) before it’ll be ready for real use.
- Merge common code: My current version has its own modified copies of code used in the CLI interface. I need to unify these again and have them using a common interface/code.
- Fix name resolution: There’s a bug where names in imported modules need to be fully qualified. I’ve solved this same bug before; I just need to track it down and do it again.
- Unify with CLI: At some point I’d really like to turn the standalone CLI interface into a wrapper around the GHC plugin. Essentially it would run GHC on the target modules with the LH plugin enabled. Then the separate .lqhi files could disappear entirely in favor of information storage in annotations in the .hi files.
- Testing: I need to get the GHC plugin integrated with our test suite, which is currently built around the CLI interface. The “Unify with CLI” step would remove the need for any extra work here.
- Find and fix
<interactive>error: There’s a pesky (GHC?) bug where, in certain cases, triggering an error on our end will cause GHC to try to read a non-existant file called
<interactive>as it tries to generate the error message. I’ve tracked this down to an exception throw in a particular of code in GHC, but I’ll need to do a lot of walking up the stack from that exception to see what’s catching it and ultimately producing the error.
- Fix test setup, drop
idirsCLI flag: LiquidHaskell currently has a command line option to specify include directories for GHC to look in when compiling the module source. This shouldn’t really be separate from the
--ghc-optionflag we already support to pass options to GHC, but it’s necessary right now given the way the test suite is set up. Once the Cabal/stack/GHC plugin support is landed, I’d like to (at some point) rework the test suite to use one of those instead of the manual test runner, then drop support for this flag once nothing else needs it.
- New parsing: A longer-term project is to replace the current parser, which has its fair share of weirdness and error cases, with a new version based on the one I implemented in my GSoC ‘15 work and using
parsec. This is a slog to get through and very prone to inducing burn-out, so I’m prioritizing other things above it for now. But it’ll also be a big help, so I want to get it done eventually.