[swift-evolution] [Review] SE-0034 Disambiguating Line Control Statements from Debugging Identifiers

[Alex Martini]

Adrian Prantl wrote:
> Nitpick: #setline is not really a statement, a better name for the production would be “line-control-directive” as it may appear everywhere a newline character may appear in the grammar.

Agreed.

The reference doesn't currently separate directives (#if and #setline and so on) into their own chapter.  Given the list of chapters it does have, Statements was the least incorrect place to discuss these.

We'll have to revisit the naming on these "statements" that aren't quite statements in the grammar.  This is very closely related to the recent change to rename "build configurations" to "conditional compilation blocks".  (As commit 6272941 did for compiler diagnostics.)


Brent Royal-Gordon wrote:
> Does that mean the filename is always required? This is uncommon in other languages that support #line, though it looks like Swift 2 imposes the same requirement.

You're correct, that is the current behavior (see below).  Do you have an example use case for setting the line number without setting the file name?



% cat -n test.swift
     1	print("On line \(#line) in file \(#file)")
     2	
     3	print("On line \(#line) in file \(#file)")
     4	
     5	#line 100
     6	
     7	print("On line \(#line) in file \(#file)")
     8	
     9	#line 100 "filename"
    10	
    11	print("On line \(#line) in file \(#file)")
    12	
    13	#line
    14	
    15	print("On line \(#line) in file \(#file)")

% swift test.swift 
test.swift:7:1: error: expected filename string literal for #line directive
print("On line \(#line) in file \(#file)")
^


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160225/c8bff8b9/attachment.html>