Macro arguments shouldn't care about unterminated strings
Rangi42 opened this issue · 2 comments
macro foo
println \1, " world!"
endm
foo "hello
macro bar
println \1 world!"
endm
bar "goodbyeerror: main.asm(4):
Unterminated string
error: main.asm(4) -> main.asm::foo(2):
syntax error, unexpected identifier
error: main.asm(4) -> main.asm::foo(2):
Unterminated string
error: main.asm(9):
Unterminated string
goodbye world!
error: Assembly aborted (4 errors)!I don't think that lexing macro arguments should be giving an "unterminated string" error. If/when the argument is expanded, its usage will still give an unterminated string error in context (e.g. when foo "hello expands to println "hello, " world!") -- except for edge cases where the whole point is that it wouldn't (e.g. when bar "hello expands to println "goodbye world!"). For example, the above output would then be:
error: main.asm(4) -> main.asm::foo(2):
syntax error, unexpected identifier
error: main.asm(4) -> main.asm::foo(2):
Unterminated string
goodbye world!
error: Assembly aborted (2 errors)!Note that you can currently avoid those "unterminated string" errors by escaping the quotes so they don't start "string within macro arg" logic, e.g. foo \"hello. Given that... maybe we shouldn't count this as a bug after all, but a weird edge test case (#1584)?
Yeah, this is only even a question for the last argument; for all the rest, it's clear that you need to escape the " to prevent the , from being part of the "string within macro arg".
Also test/asm/raw-macro.args.asm covers this already, so no need to add another weird test case.