-
Notifications
You must be signed in to change notification settings - Fork 197
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
#433, make hints spanning multiple modules/declarations
- Loading branch information
1 parent
1af1723
commit 7bb10df
Showing
4 changed files
with
19 additions
and
17 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ndmitchell this is a breaking API change. The Intellij Haskell plugin uses the json API to display hlint suggestions and to apply them. This change broke the Hlint integration because it expects not a list for the module value.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ndmitchell sorry, I see, it is indicated as breaking API change....
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the ping @rikvdkleij - had I realised it would break a real user I might not have bothered, or at least made it gracefully fall back in the case when there was only a single point. Is it worth doing that now? Given Intellij is so tightly bound to precise details is it worth restricting to a hard 0.1 upper bound? I don't often break the API, so you usually get ~30 releases between 0.1 marks. Let me know how I can make it easier, or at least less surprising.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ndmitchell Thanks for your helpful reply!
No, it does not really help because it will still raise an error when more than one point.
That would mean I have set upper bound for each Stackage LTS version or GHC version.
Currently the plugin builds the Hlint version of the Stackage LTS version which is used by the project to be sure that Hlint always is built without errors.
So yeah, I think setting an upper bound is the best solution to prevent this kind of error. And when I create new release of plugin I check if there is a new Hlint version.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you mean if I am developing a project with Stackage 11.1, then HLint will come from 11.1 too? There's no need to do that, you should be able to pick an HLint from whatever Stackage IntelliJ is used to, and then you could upgrade HLint only when you rerelease IntelliJ. That would guarantee everything always matched.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
But how do I know that that specific HLint version is built for every Stackage version (and so also GHC version)?
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not quite sure what you mean. You can take an HLint, any HLint version, and run it on any code/GHC. HLint does not require to be compatible with your project, or with your GHC version - it doesn't use the GHC API. Even if you code won't compile, HLint can still run on it. It's just a parser and some guesses.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I understand but in the past I had some compatibility problems with building specific version of HLint against any Stackage LTS version. But I will take a look again. I guess I have to help the Stack build to set the right dependencies if that HLint version is depending on library versions which are not in that Stackage LTS version.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I test HLint with every Stackage version, and HLint itself is in Stackage, so it should be robust - please report any issues you find.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to get HLint 2.1.1 build with Stackage LTS version 6.35 (GHC 7.10.3) but after finding the right dependencies and building happy 1.19.5, I got this compilation error in HLint:
Build command:
stack build hlint-2.1.1 aeson-1.3.0.0 haskell-src-exts-1.20.2 haskell-src-exts-util-0.2.2 semigroups-0.18.4 th-abstraction-0.2.6.0 text-1.2.3.0 transformers-compat-0.5.1.4 transformers-0.5.5.0
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant:
That should work indefinitely, and I just tested it now.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But that is building HLint version 1.9.35. That is how IntelliJ plugin currently works.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused... I thought you built with whatever stack the user project was? Whereas I'm suggesting you pick a single resolver and only upgrade HLint when you make a new release of IntelliJ.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe some context. An IntelliJ user expects that everything works out-of-the-box :-) He has an Haskell Stack project with in his stack.yaml resolver 6.35. IntellIJ wants to build HLint and does not want to install HLint globally because maybe user has also projects of other LTS or GHC versions. So IntelliJ is using LTS/GHC version of project and builds it for that project. This version of HLint is only "visible" for that project.
Also, if I would pick a resolver, it could happen that plugin has to download and install another GHC version "somewhere".
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe there is no other choice then let the user install HLint (globally). But then plugin has to "force" a specific version range of HLint.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Working out of the box seems good.
An alternative would be that IntelliJ creates its own project, using its own resolver, and installs hlint to its own IntelliJ specific place. E.g. IntelliJ 3.2 ships with knowledge of LTS-6.35, so IntelliJ does
stack build hlint --resolver=LTS-6.35 --stack-root=IntelliJ-3.2
, to put HLint in a local-to-IntelliJ-3.2 directory, so no global install, but IntelliJ has strongly locked down the HLint it gets to use.7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, this not the case for HLint but still I do not want to change which binaries are on the user his PATH.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing a
stack build
won't change what is on the users path - stack builds are sealed - no global changes.7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly :-)
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds good. Could only happen that IntelliJ will trigger a GHC install but that is not really a big problem if you have good Internet connection.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ndmitchell Many thanks for thinking along!!
Maybe I will do the same for external dependencies as stylish-haskell and hindent. Intero not because that one is really GHC specific.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes a lot of sense, and indeed making Intero the exception. Thanks for maintaining and improving IntelliJ - I know it's a lot of work, but it is valuable! Do shout in future if there is something that HLint can make easier.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Yes, it is 😄
Other question. Can I do the same for the Hoogle (executable) as for HLint? According to the dependencies it should be but just to be sure.
7bb10df
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, Hoogle will work exactly the same way.