Skip to content
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

[SR-12346] Parser does not process backslash escapes in many contexts #54780

Open
beccadax opened this issue Mar 11, 2020 · 1 comment
Open
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself parser Area → compiler: The legacy C++ parser Windows Platform: Windows

Comments

@beccadax
Copy link
Contributor

Previous ID SR-12346
Radar rdar://problem/60341405
Original Reporter @beccadax
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Parser, Windows
Assignee None
Priority Medium

md5: 9ac3bdf1996a8aee2e14568b2a29cf92

Issue Description:

When parsing constructs like #sourceLocation(file:) or @available(message:), the parser uses the function Parser::getStringLiteralIfNotInterpolated() to extract the text from the literal. This function doesn't call Lexer::getEncodedStringSegment() to process backslash escapes in the string—it simply extracts the source file's text directly. However, the lexer still assumes that the string literal will have its escapes processed, so it rejects "invalid" escapes.

This has a number of bad effects. The worst is that there's no way to specify a #sourceLocation with a backslashed Windows path:

#sourceLocation(file: "a\b.swift", line: 10)    // error: invalid escape sequence in literal

#sourceLocation(file: "a\\b.swift", line: 10)
#error("where am I?")    // a\\b.swift:10:8: error: where am I?

But it also means that we don't process escapes in @_private(sourceFile:) import, @available(..., message:), #assert, etc.

We should correct these bugs by updating Parser::getStringLiteralIfNotInterpolated() to extract the string's contents with Lexer::getEncodedStringSegment(). However, this will require us to change how Parser::getStringLiteralIfNotInterpolated() and perhaps its callers manage memory, because they currently assume that the StringRef is backed directly by a source buffer and will never be freed.

@beccadax
Copy link
Contributor Author

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself parser Area → compiler: The legacy C++ parser Windows Platform: Windows
Projects
None yet
Development

No branches or pull requests

1 participant