Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Emit reference to instance method instead class method #73

Open
robinp opened this issue Sep 21, 2017 · 3 comments
Open

Emit reference to instance method instead class method #73

robinp opened this issue Sep 21, 2017 · 3 comments

Comments

@robinp
Copy link
Collaborator

robinp commented Sep 21, 2017 •
edited

When the instance is fully resolved.

Basic plan (probably doesn't handle edge cases etc):

  • see if HsVar's id's idDetails is ClassOpId (also isClassOpId_maybe)
  • if so, get the classTyCon from the Class of the ClassOpId
  • look if the HsWrap wrapping the HsVar contains WpEvApp (EvId x), where x's type is of form TyConApp <the classTyCon> ...
  • if we found it, then x is the dFunId... but how do we go from that (knowing the Class and the method name) to the instance method var?

Idea: get the module of the dFunId name using nameModule, then GHC.getModuleInfo on it. Then we can lookup the ClsInst list in that module... but it doesn't refer the actual members, just the DFunId, again. Ok, not the best idea. Can we take that DFunId apart?

Idea#2: assign Tick to instance methods by concatenating the DFunId tick with the method name, so it's trivial to construct the Tick reference from the locally available info. Sounds like a much better idea.

This can work - but the instance method decls need to be taken from the typechecked tree, where we can harvest the related dFunId (the abe_mono is easier to find the classTyCon, since there's no context) by looking at which $c... gets applied in the $d... binding.
@robinp
Copy link
Collaborator Author

robinp commented Oct 6, 2017

Mental note. From Simon:

well the HsWrapper might have something much more complicated than a DFunId. It might need to construct the dictionary for Eq [a] from the DFun for Eq [a] and a dictionary for Eq a.

Interesting. Could for start just point to the "outermost" instance (here Eq [a]), but ideally (if the callsite's tc dict is fully saturated) we could even generate a virtual, monomorphic linked source (where clicking class methods used in the outermost instance's implementation links to the dependent instance's.....). But that seems deep.

Alternatively, following a link to a (virtual / overloadded / classmethod ....) thing should take into account the "current stack" or "current context", and that would have to be rolled along.

@robinp
Copy link
Collaborator Author

robinp commented Jun 8, 2018

+@mpickering for insights.

@robinp robinp mentioned this issue Aug 23, 2018
Open
@robinp
Copy link
Collaborator Author

robinp commented Oct 2, 2019

Note: this might come to HIE, see https://gitlab.haskell.org/ghc/ghc/merge_requests/1286 as mentioned in https://gitlab.haskell.org/ghc/ghc/wikis/hie-files:

Recently, I extended .hie files to capture information about typeclass evidence that is generated by GHC. This can help you debug generated evidence for your code, as well as enable features like "jump to implementation", which will take you to the definition of the instance(s) that will be actually used when you invoke a class method or any other method that takes some evidence as a parameter.

It seems to be around https://gitlab.haskell.org/ghc/ghc/merge_requests/1286/diffs#7f924eb82ea52b493e50fc467c301adb6a0eaf32_419_517 .

The existing feature

We traverse the Renamed and Typechecked AST to collect the following info about each SrcSpan: ... Its assigned type(s)(In increasing order of generality) ...

seems to capture the monomorphized type, but not the instance used to get it? Not sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@robinp