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
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:
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.
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 toprintln "hello, " world!"
) -- except for edge cases where the whole point is that it wouldn't (e.g. whenbar "hello
expands toprintln "goodbye world!"
). For example, the above output would then be:The text was updated successfully, but these errors were encountered: