fix(typescript): Bad handling of semicolons in commutative merging of class bodies #585
No reviewers
Labels
No labels
Compat/Breaking
Kind
Bad merge
Kind
Bug
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
New language
Kind
Security
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: mergiraf/mergiraf#585
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "tsx_separators"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a minimized version of a bug reported by Stainless.
The
;
are not recognized as separators in theclass_body
, so the merging algorithm is treating them as independent elements that are being added.One solution would be to fix the Typescript grammar so that those elements are bundled into the attributes they come at the end of.
One could perhaps come up with other solutions on Mergiraf's side, but it looks like we would need to have to relax the current restriction we have that each separator associated to a commutative group must be equal to the default separator for the commutative parent, up to whitespace.
You probably mean creating a
ChildrenGroup
for(public)_field_definition
s which has;
as its separator? That honestly sounds like the most logical solution to the problem at hand, even if it would require relaxing the separator restriction, because the latter is imo also pretty sensible, even on its own. Should I try to implement that?I think the only problematic place is
commutatively_merge_lists
, where we first callkeep_content_only
on each side, which removes the separators and the delimiters, in order to be able to callchild_separator
to find what the actual separator is. I think the way we would adjust that is to not usekeep_content_only
at all, and instead makechild_separator
smarter:ChildrenGroup
it considers:CommutativeParent
's default separator in this calculation)This would be somewhat more computationally expensive, but I don't really see a way around it?...
One question -- currently, we first map each node to a leader (in
keep_contents
), then map those back to all representatives, and for each of those, check whether they're extra. But isn't the "extraness" of a leader the same as of all its representatives, similarly to the grammar kind?Result::ok_or
5640ce4143ChildrenGroup
forpublic_field_definition
So, here's what I came up with. Interestingly enough, it deviated wildly from the original code during development, but ended up returning to more or less the same thing in the end
WIP: fix(typescript): Bad handling of semicolons in commutative merging of class bodiesto fix(typescript): Bad handling of semicolons in commutative merging of class bodiesReally cool, thank you so much for the fix! I think it makes a lot of sense like this.
2e663fb381
toed788431dc
Thank you, I am quite proud of this one:)
ed788431dc
to3a2c6f985c
The effect on merge output seems unambiguously positive too (the timing difference shouldn't be meaningful though, the load on the machine was variable):
*.ts
How nice!