Add 'imported-from' command.

[DanielG]

No description provided.

[carlohamalainen]

So I'm right to clone the main repo and push directly to this branch?

[DanielG]

Yeah, you can just add this repo as a remote to your existing repo though, no need to re-clone.

[lierdakil]

WRT tests, I should probably tweak test code so it fails early, but here's an actual problem:

>>>> Cabal errors begin
Warning: /home/travis/build/DanielG/ghc-mod/ghc-mod.cabal: Ignoring unknown
section type: custom-setup
cabal: Could not resolve dependencies:
trying: ghc-mod-5.6.0.0 (user goal)
trying: base-4.8.2.0/installed-0d6... (dependency of ghc-mod-5.6.0.0)
next goal: haddock-api (dependency of ghc-mod-5.6.0.0)
rejecting: haddock-api-2.17.3, 2.17.2, 2.16.1, 2.16.0 (conflict: ghc-mod =>
haddock-api<2.16)
rejecting: haddock-api-2.15.0.2, 2.15.0.1, 2.15.0 (conflict:
base==4.8.2.0/installed-0d6..., haddock-api => base>=4.3 && <4.8)
Dependency tree exhaustively searched.
<<<< Cabal errors end

[lierdakil]

Okay, 7.10 fixed. 7.8 is still failing, in part due to test files not compiling under 7.8 (f.ex. ImportedFrom03.hs has some instance-related fails), and in part I honestly don't know why, but it throws GMENoVisibleExports.

[carlohamalainen]

The failures on 7.8.4 are my fault, have reproduced them on my laptop. I'll look into it.

[carlohamalainen]

@DanielG I've gone through all your comments, happy for final review now.

[DanielG]

I'm doing a cleanup pass right now so don't bother fixing any of the things I'm about to comment on. Those are just FYI.

[DanielG]

I replaced this entire function with modAs == moduleOfQualifiedName userQualSym. Don't you think a datatype called MySymbolUserQualified should maintain the invariant that the module it contains is actually qualified ;)

The way we deal with this usually is by using smart constructors (mkSymbolUserQualified etc.) that check this invariant and only use those to construct that type. (optionally moving the type definition to a separate module that doesn't export the constructor so the mkFun in the only way to make a value of that type.

[DanielG]

thisExports :: [FullyQualifiedName] but hiding' :: [QualifiedName], those will never match AFAIU. The type system could've saved you here. Next time use it :p

[DanielG]

Hmm nevermind, but I just realized the whole parsing below is completely pointless. Just keeping more information by making FullyQualifiedName a record is much easier.

[lierdakil]

I think at this point this is "good enough". I could probably refine this ad infinum given the chance, but I think I have to stop at some point, and this particular point seems as good as any.

@DanielG, if you could review this, that would be cool.

[DanielG]

Looks good, though we had a mode to just print the package+module name instead of the full haddock path (see comments following #810 (comment)) . @lierdakil did you remove that?

Also we seem to have reverted to using error to report user facing errors which we fixed before, see fa1417a for example.

[lierdakil]

Looks good, though we had a mode to just print the package+module name instead of the full haddock path (see comments following #810 (comment)) . @lierdakil did you remove that?

Yep, missed that bit. I basically reimplemented the whole deal from scratch while stealing bits and pieces from @carlohamalainen's implementation when appropriate, so I was bound to miss something.

Although I should point out that while hackage url can be, in general, inferred from package id, module and symbol, local haddock path can not, and current implementation prefers the latter if it's available. So there's that. I think we can solve this problem in another way though, see below.

Also we seem to have reverted to using error to report user facing errors which we fixed before, see fa1417a for example.

Reason being, those errors never leave the scope of the function, so my reasoning was that why define exceptions that are local to the module. Now that I think about it, I should probably make it throw GME exceptions and handle those downstream, since it might be more useful to library users. Sorry, didn't think about that -- was OD'ing on caffeine at the time, so I kinda rushed a bit.

Also while on the topic of library users. I've been bitching about library interface for a while (#696), and now seems as good a time as any to start imposing at least some structure on the returned values. So what do you think about returning [ImportedFromResult] instead of String? We can make an instance of TextOutput ImportedFromResult (and also TextOutput a => TextOutput [a]) to convert that to String in ghc-mod binary. Also we can dump the whole batch of information out, including package name and hackage url here, without having to pass a ton of flags to the function itself (we could instead add those into TextOutput instances -- e.g. by defining an instance-specific output config)
Thoughts?

[DanielG]

Returning proper datatypes instead of strings sounds lovely actually I don't see why we shouldn't.

[carlohamalainen]

I updated this PR against the master branch but I'm not seeing any status from travis - is there something else that I have to do?

[DanielG]

We've stopped using travis a while ago. The builds are now on Gitlab(CI) but it looks like the repo mirroring has broken, I'm looking into that. If you have a gitlab account I can add you there so you can push this branch to the other repo as well, which will trigger a build.

FYI you can actually configure git to push to multiple repos at once when you push to a remote, see https://gist.github.com/bjmiller121/f93cd974ff709d2b968f

[carlohamalainen]

Just made an account: https://gitlab.com/carlohamalainen

[DanielG]

Done

[DanielG]

@carlohamalainen are you still working on this? Do you need help with the new CI setup or something?