Consider the following code:
///|
test {
let multi_str = "a\r\nb\r\nc"
inspect(multi_str)
}The expected output is a\r\nb\r\nc. Currently on the moon side, when executing moon test --update, it will split by \n, and transform the rest of the code as is into something like "#|\{rest}". This is problematic with \r, because now the generated snapshot will be #|a\r\n #|b\r\n #|c\r\n (here the \r\n are the corresponding ascii char. But the compiler will consider \r\n as line separator, so the final string generated will be considered as a\nb\nc\n, which does not correspond to the actual code. Thus, moon test --update will never succeed.
The other issue happens when we have \0. Following the same principle, the updated file will have the character \0 inside the file. But tools like rg will consider it as binary file and refuse to work correctly.
Therefore, I propose that inspect rejects the strings that contains ascii control sequences, except \n, and strings that contain zero-width characters.
Consider the following code:
The expected output is
a\r\nb\r\nc. Currently on themoonside, when executingmoon test --update, it will split by\n, and transform the rest of the code as is into something like"#|\{rest}". This is problematic with\r, because now the generated snapshot will be#|a\r\n#|b\r\n#|c\r\n(here the\r\nare the corresponding ascii char. But the compiler will consider\r\nas line separator, so the final string generated will be considered asa\nb\nc\n, which does not correspond to the actual code. Thus,moon test --updatewill never succeed.The other issue happens when we have
\0. Following the same principle, the updated file will have the character\0inside the file. But tools likergwill consider it as binary file and refuse to work correctly.Therefore, I propose that
inspectrejects the strings that contains ascii control sequences, except\n, and strings that contain zero-width characters.