You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
beccadax opened this issue
Mar 11, 2020
· 1 comment
Labels
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler in itselfparserArea → compiler: The legacy C++ parserWindowsPlatform: Windows
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.
The text was updated successfully, but these errors were encountered:
bugA deviation from expected or documented behavior. Also: expected but undesirable behavior.compilerThe Swift compiler in itselfparserArea → compiler: The legacy C++ parserWindowsPlatform: Windows
Additional Detail from JIRA
md5: 9ac3bdf1996a8aee2e14568b2a29cf92
Issue Description:
When parsing constructs like
#sourceLocation(file:)
or@available(message:)
, the parser uses the functionParser::getStringLiteralIfNotInterpolated()
to extract the text from the literal. This function doesn't callLexer::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: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 withLexer::getEncodedStringSegment()
. However, this will require us to change howParser::getStringLiteralIfNotInterpolated()
and perhaps its callers manage memory, because they currently assume that theStringRef
is backed directly by a source buffer and will never be freed.The text was updated successfully, but these errors were encountered: