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

Implement 'Attempt to fill hole' code action #431

Merged
merged 69 commits into from
Oct 3, 2020

Conversation

TOTBWF
Copy link
Contributor

@TOTBWF TOTBWF commented Sep 25, 2020

This PR brings in the new version of refinery in order to implement the Attempt to fill hole code action. This action will use the tactic machinery to try to synthesize a term that matches the type of the hole.

@jneira
Copy link
Member

jneira commented Sep 25, 2020

What do you think about converting it in github "draft" until is ready to review (to enforce the WIP tag)?

@TOTBWF TOTBWF marked this pull request as draft September 25, 2020 14:49
@jneira jneira linked an issue Oct 1, 2020 that may be closed by this pull request
@isovector
Copy link
Collaborator

@pepeiborra this is ready for review when you have some time :)

import SrcLoc


-- TODO(sandy): Consolidate this with LocalBindings
Copy link
Collaborator

Choose a reason for hiding this comment

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

It would be nice if you made a PR on ghcide for this

Copy link
Collaborator

Choose a reason for hiding this comment

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

Done (I think)

haskell/ghcide#845

case splitTyConApp_maybe $ unCType t of
Nothing -> throwError $ GoalMismatch "destruct" g
Just (tc, apps) -> do
let dcs = tyConDataCons tc
Copy link
Collaborator

Choose a reason for hiding this comment

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

Are these DataCons in scope? Are they even known to be exported?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Neither. I don't think the first is important; other plugins can suggest the import.

That being said, preventing unexported datacons from being generated is more interesting, Is there an easy way we can check that?

= take 1
. fmap toLower
. filterReplace isSymbol 's'
. filterReplace isPunctuation 'p'
Copy link
Collaborator

Choose a reason for hiding this comment

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

replacing symbols and punctuation like this doesn't really need like it will lead to good names.

Copy link
Collaborator

Choose a reason for hiding this comment

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

No, but without it we run into problems giving names for type operators; it's really hard to come up with a name for a tycon called (:<!>), eg.

(tcmod, _) <- MaybeT $ runIde state $ useWithStale TypeCheck nfp
let span = rangeToRealSrcSpan (fromNormalizedFilePath nfp) range'
-- TODO(sandy): unclear if this span is correct; might be
-- pointing to the wrong version of the file
Copy link
Collaborator

Choose a reason for hiding this comment

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

fix this TODO by applying the position mapping returned by useWithStale

Copy link
Collaborator

Choose a reason for hiding this comment

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

done

{ ts_skolems :: [TyVar]
, ts_unifier :: TCvSubst
, ts_used_vals :: Set OccName
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

These should all probably be strict fields

Copy link
Collaborator

Choose a reason for hiding this comment

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

Done

Copy link
Collaborator

@pepeiborra pepeiborra left a comment

Choose a reason for hiding this comment

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

I'm not really qualified to review this, but the ghcide and perf bits look fine to me. Can't wait to play with the new features!

@georgefst georgefst mentioned this pull request Oct 3, 2020
@pepeiborra pepeiborra merged commit 2be03cc into haskell:master Oct 3, 2020
@pepeiborra
Copy link
Collaborator

Merged!

@isovector
Copy link
Collaborator

Thanks!!

@michaelpj
Copy link
Collaborator

(Raised on IRC, but repeating)

This PR makes the ghcide submodule point to a commit that isn't on any branch in the ghcide repository. I think maybe it used to be on a PR branch, but that PR branch got force-pushed to. This makes various git-based tools choke on the checkout. I think fixing it should be as simple as pushing a branch to ghcide that contains the commit in question.

@isovector
Copy link
Collaborator

Submodules strike again!

The reference should be pointed to haskell/ghcide#845

@alanz
Copy link
Collaborator

alanz commented Oct 6, 2020

Raised on IRC, but repeating)
This has been resolved

pepeiborra added a commit that referenced this pull request Dec 27, 2020
* Add ModLocation to Import type

* Add ModuleNames to dependency information

With @adamse

* Clarify ModLocation assumption

* Add a comment on use of rwhnf

* newtype ArtifactsLocation

Co-authored-by: Marcelo Lazaroni <[email protected]>
@isovector isovector deleted the auto branch July 19, 2021 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow using LambdaCase in case splitting plugin
7 participants