-
Notifications
You must be signed in to change notification settings - Fork 1
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
Allow typedef deletions regardless of whether type is in use #1153
Conversation
9f121c1
to
f45ba15
Compare
What's the status of this PR? How much work remains before it's ready for review? |
None! I just somehow forgot to ask for a review. |
forTypeDefConsFieldNode con index id l Editable tydefs defs tdName td = | ||
forTypeDefConsFieldNode con index id l Editable _ _ _ td = |
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 worth removing these arguments entirely?
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. I suspect we may well re-add them at some point, and even with them unused, the uniformity helps in simplifying the definition of Primer.API.availableActions
. Ideally we'd probably refactor this to pass around a record for the common fields, in which case we'd be unlikely to complain that not all fields of the record are used in every function which receives it.
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.
Fair point. I don't have strong opinions either way.
updateType = transformM \case | ||
TCon _ n | n == d -> tEmptyHole | ||
e -> pure e |
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.
It is somewhat odd to have updateExpr
defined above in a let
, but updateType
defined below in a where
. Any particular reason?
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.
Agreed, but we mostly use where
in the other cases, but updateExpr
can't go there because then def
would be out of scope. It's a bit weird, but I don't think it's worth changing.
primer/test/Tests/Action/Prog.hs
Outdated
unit_DeleteTypeDef :: Assertion | ||
unit_DeleteTypeDef = progActionTest | ||
( defaultProgEditableTypeDefs | ||
$ sequence | ||
[ do | ||
x <- emptyHole `ann` (tcon tT `tapp` tcon (tcn "Bool") `tapp` tEmptyHole) | ||
astDef "def" x <$> tEmptyHole | ||
] |
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.
Might be better to also use the type's constructors at term level, both as constructors and as patterns in a case
primer/test/Tests/Action/Prog.hs
Outdated
unit_DeleteCon :: Assertion | ||
unit_DeleteCon = progActionTest | ||
( defaultProgEditableTypeDefs | ||
$ sequence | ||
[ do | ||
x <- | ||
case_ | ||
(emptyHole `ann` (tcon tT `tapp` tcon (tcn "Bool") `tapp` tcon (tcn "Int"))) | ||
[ branch cA [("x", Nothing), ("y", Nothing), ("z", Nothing)] emptyHole | ||
, branch cB [("s", Nothing), ("t", Nothing)] emptyHole | ||
] | ||
astDef "def" x <$> tEmptyHole |
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.
Could we also use cA
as a constructor? (Maybe in the RHS of the cB
branch)
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.
Looks pretty good. I have a handful of small comments and one large one that has triggered me to put "Request changes": the issue about scoping when deleting a field (#1153 (comment))
f45ba15
to
ebafd4f
Compare
Signed-off-by: George Thomas <[email protected]>
I haven't found any particular test case which is affected by this, but it seems safer, and will also make it easier to factor out this code. This appears to be an oversight from `257cb77: feat: Implement actions for editing type parameter kinds`. Signed-off-by: George Thomas <[email protected]>
Signed-off-by: George Thomas <[email protected]>
ebafd4f
to
e906f3a
Compare
Actually, I think it was because I had intended to add a few more tests. I'm just finishing these now, along with @brprice's suggested tests. |
e906f3a
to
81f235a
Compare
This includes fixing up expressions utilising the deleted type/constructor/field so that they still make sense. Mostly this involves replacing subexpressions with holes. Note that this does not yet include deleting type parameters, which we still cannot modify at all when the type is in use. But we aim to relax this restriction as well shortly. We add a unit tests for each action. Note that we didn't actually have any for the old behaviour, due to time constraints when that was implemented. Although the `tasty_available_actions_accepted` property test caught a lot of issues for us. Signed-off-by: George Thomas <[email protected]>
81f235a
to
26aaa83
Compare
Closes #401.
In the absence of a full feature request, due to this being a fairly straightforward extension of the ideas of #267 with little scope for controversy (by contrast, #402, which I've started some initial work on alongside this, is more exploratory, and I believe will justify a formal feature spec), the behaviour implemented here is as follows:
Deleting a type
KType
toKHole
Deleting a constructor
Deleting the nth field of a constructor