Skip to content
This repository has been archived by the owner on Apr 25, 2020. It is now read-only.

Merge ghc-imported-from into ghc-mod #810

Conversation

carlohamalainen
Copy link
Collaborator

Merging ghc-imported-from into ghc-mod: https://github.com/carlohamalainen/ghc-imported-from

@carlohamalainen
Copy link
Collaborator Author

Struggling to get this to build on ghc-7.6.3 due to dependencies on process-streaming. Will sort it out.

@@ -174,9 +175,10 @@ Library
, bytestring < 0.11
, binary < 0.9 && >= 0.5.1.0
, containers < 0.6
, cabal-helper < 0.8 && >= 0.7.1.0
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't remove the bounds please :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted ghc-mod.cabal:

commit 875b5137a867416bfa7416493a0aac0165c91222
Author: Carlo Hamalainen <carlo@carlo-hamalainen.net>
Date:   Fri Jul 15 21:09:59 2016 +1000

    Revert ghc-mod.cabal to current master.

Just ve -> ve
Nothing -> let pname' = ((head $ separateBy '-' pname) ++ ":" ++ thisModuleName) in
fromMaybe
(throw $ GMENoVisibleExports thisModuleName pname')
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, monadic context -> inline that failure.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

L.H.GM.Error.liftMaybe should be applicable here.

@DanielG
Copy link
Owner

DanielG commented Aug 8, 2016

Phew, long review. We're getting there. It's your bad luck I had too much time on my hands to do a thorough review. Most of the stuff is pretty nitpick though so we ought to be about done. I really have to write some code style guidelines one of these days :)

So never mind the thing about merging early I said before probably best not to loose all those comments.

@DanielG
Copy link
Owner

DanielG commented Aug 8, 2016

I'm not sure what to do about the find-module stuff now, I did see a comment mentioning pkgDoc so obviously you were already aware of it. What's wrong with using it over what you're doing there?

@@ -282,7 +282,7 @@ ghcPkgFindModule mod = do

shortcut [ stackGhcPkgFindModule rp mod
, hcPkgFindModule rp mod
, _ghcPkgFindModule rp mod
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI in GHC a leading underscore denotes a typed hole but you can also use it to suppress the "unused symbol" warning when you then go on to define that symbol. I'm not aware of what "python style" you refer to here.

@DanielG
Copy link
Owner

DanielG commented Aug 9, 2016

@lierdakil tests for 7.10 are failing with

0.05s$ stack --no-terminal build --test --no-run-tests
Could not parse './ghc-7.10.3.yaml':
AesonException "Error in $.packages[0]: failed to parse field 'packages': failed to parse field packages: (Invalid package identifier: \".\",\".\")"

I have no idea what's going on there.

@@ -552,7 +552,10 @@ refineVisibleExports getHaddockInterfaces exports = mapM f exports
qexports = qualifiedExports mexports -- e.g. ["base-4.8.2.0:GHC.Base.Just", ...]
mVisibleExportsMap <- getVisibleExports getHaddockInterfaces pname

let visibleExportsMap = fromMaybe (throw $ GMEString $ "ImportedFrom: visible exports map is Nothing") mVisibleExportsMap
visibleExportsMap <- case mVisibleExportsMap of
Copy link
Owner

@DanielG DanielG Aug 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you misunderstood, there are three kinds of failures:

  • A pure exception
do let foo = throw "whatever"
   return foo
  • An excpetion where a monadic value should be
do throw "whatever"
  • An ExceptT/MonadError failure
do throwError $ GMEString "whatever"

The differences are subtle but in general the first two kinds are annoying since you need to explicitly catch the exceptions whereas the last one just always gets returned as a Left by runGhcModT.

The difference between 1) and 2) is important though: throw "whatever" >> return "foo" will always crash when run, let foo = throw "whatever" in return (foo, "bar") will only crash when you touch the fst of that tuple! (lazyness and such)

The GhcModError stuff should always be returned via throwError where possible. All you really had to do was to replace fromMaybe with liftMaybe :)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also fail is equivalent to throwError . GMEString which is why I suggested you use that before.

@DanielG
Copy link
Owner

DanielG commented Aug 9, 2016

Actually let's continue in #823, it's easier if we have a shared branch.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants