Ensure FormatRawStringLiteral produces valid swift syntax for special characters #3256
+12
−17
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Currently, the
FormatRawStringLiteralrefactoring can produce invalid Swift code when moving from extended delimiters to a regular string literal. For example:#"""#becomes"""(Unmatched multi-line literal)#"He says "Hi""#becomes"He says "Hi""(Syntax error)#"C:\Users"#becomes"C:\Users"(Invalid escape sequence)This PR adjusts the logic to ensure that the minimum number of # symbols is is always sufficient to represent the content safely. The minimum safe number of # delimiters is now 1.
Alternative: Auto-escaping on hitting string literal
I have also explored an implementation where it can convert these to string literals while injecting the escape characters ( eg:
#"He says "Hi""#->"He says \"Hi\"").I can use this alternative, or a different approach if the preference is to favor standard literals over delimited ones. Open to suggestions!
Test Plan:
swift format -iprLinked Issue
Closes swiftlang/sourcekit-lsp#2465