Skip to content

Remove unnecessary guard in TreeMap #18368

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

Merged

Conversation

nicolasstucki
Copy link
Contributor

This guard was added in fb09e82 but does not seem to be necessary. Note that UntypedTreeMap handles the case DerivingTemplate explicitly.

@nicolasstucki nicolasstucki requested a review from odersky August 9, 2023 08:41
@nicolasstucki nicolasstucki marked this pull request as ready for review August 9, 2023 08:41
@@ -1595,7 +1595,7 @@ object Trees {
cpy.DefDef(tree)(name, transformParamss(paramss), transform(tpt), transform(tree.rhs))
case tree @ TypeDef(name, rhs) =>
cpy.TypeDef(tree)(name, transform(rhs))
case tree @ Template(constr, parents, self, _) if tree.derived.isEmpty =>
Copy link
Contributor

Choose a reason for hiding this comment

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

The guard made sure nothing was forgotten in the transform. Instead of a guard it could be an assert. But then we could not fill in the missing case (where a derived is not empty) in transformMoreCases.

So I think overall it's best to leave it in. Maybe add a comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did test it locally with an assert and then removed it. I could add back the assert with a meaningful message. It might be clearer this way that the Template was not supposed to have a derived set.

Are we only supposed to have non-empty derived for untyped templates? Or are there cases where the typed template is expected to have something in derived?

Copy link
Contributor

Choose a reason for hiding this comment

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

We don't know. As you tested, there are no occurrences where derived is empty when we transform. But that is not necessarily true for the future. With the original scheme we fall through into transformMoreCases when we see such a tree where we would fail unless transformMoreCases explicitly provides for it. I think that's what we want. An assert is worse since it prevents the handling of the case. The chance is high that if such a case arises in the future, and we hit the assert, we just remove it, since we have now found a legitimate case where it mis-fires. But that would be bad since then other maps would have a hole where they silently drop the derived field. So I really think the original code is the best possible design.

@nicolasstucki nicolasstucki force-pushed the remove-unnecessary-guard-in-TreeMap branch from 25b26ec to 4db5222 Compare August 9, 2023 09:11
@nicolasstucki nicolasstucki force-pushed the remove-unnecessary-guard-in-TreeMap branch from 4db5222 to 7dd263d Compare August 9, 2023 09:20
@odersky odersky merged commit 9e1a5d8 into scala:main Aug 9, 2023
@odersky odersky deleted the remove-unnecessary-guard-in-TreeMap branch August 9, 2023 12:01
Kordyjan added a commit that referenced this pull request Dec 8, 2023
Backports #18368 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
@Kordyjan Kordyjan added this to the 3.3.2 milestone Dec 14, 2023
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.

3 participants