Fix fatal error caused by switch cases without any statements (#473)#499
Fix fatal error caused by switch cases without any statements (#473)#499allevato merged 1 commit intoswiftlang:mainfrom
Conversation
|
@allevato Would you be able to review this PR and give feedback if necessary? It’s a relatively small and safe PR. I’m not sure if you’re the right person to ping for a review, but you seem to be the most active maintainer (please direct me to the correct person if I’m wrong). If there are any other steps I need to follow before getting the PR reviewed, please let me know. |
allevato
left a comment
There was a problem hiding this comment.
Thanks for catching this; I agree that we don't want the formatter crashing under any circumstances (especially for code that parses correctly but is rejected later during compilation).
Will kick off CI on the companion PR in swift-syntax after my other requests are done processing and merge when it's ready.
|
Thanks, out of interest what do you mean by the companion pr in swift-syntax? |
We don't have swift-ci directly set up on swift-format yet, but I can kick it off indirectly by linking to this PR from this dummy PR that uses the trigger. I don't want to dirty up swift-syntax with multiple dummy PRs though, so I need to wait for each one to finish and report the results before starting the next. |
Fix fatal error caused by switch cases without any statements (swiftlang#473)
The issue can be reproduced on main by formatting the following snippet:
The code isn't valid Swift of course, however it shouldn't cause a fatal error, and in my opinion it shouldn't prevent formatting of the code (because intent is clear). However, I'm not sure of the official position of this project on how invalid code should be handled.
Note that adding a comment in the
ycase doesn't effect whether a fatal error occurs.I have added a test that covers formatting of empty cases and after my relatively minimal (and commented) changes it no longer crashes. The issue occurred because in the situation where a case is empty, the opening break and
opentoken are added after the same syntax token as the closing break andclosetoken. These two sets of tokens are added one after another, and because of the implementation ofafter, the two sets end up getting swapped when constructing the token stream. Thus, the closing break andclosetoken end up preceding the opening break andopentoken causing the fatal error.