-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Remove unnecessary guard in TreeMap #18368
Conversation
@@ -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 => |
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.
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.
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.
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
?
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.
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.
25b26ec
to
4db5222
Compare
4db5222
to
7dd263d
Compare
Backports #18368 to the LTS branch. PR submitted by the release tooling. [skip ci]
This guard was added in fb09e82 but does not seem to be necessary. Note that
UntypedTreeMap
handles the caseDerivingTemplate
explicitly.