Single quote strings break something about CRLF

[ondrejmirtes]

Version: since 3.3.3

This bug report is about this commit: 22e384d

Bug Description

After encoding and decoding a string that contains \r\n, the resulting array isn't equivalent to the previous one.

When I revert the change from 22e384d

Steps To Reproduce

I have a gist that shows before/after: https://gist.github.com/ondrejmirtes/560e8ecb616bce26575a631f4fc86af1/revisions

On line 52 you can see the difference:

Before: ^PHPDoc tag @param has invalid value \\(\r
After: #^PHPDoc tag @param has invalid value \(

Decoding this again with nette/neon results in a different string.

If I re-add again \r to the neon file like this:

#^PHPDoc tag @param has invalid value \(\r

It makes it alright again.

Expected Behavior

Encoding and decoding a string should result in the same string.

Possible Solution

I've opened a PR with a failing test, not sure how to fix it: #71

[dg]

Fixed and thanks for detailed report.

By the way, wouldn't it be better to normalize those 'messages' and remove the \r from them?

[ondrejmirtes]

Thank you for the fix!

It's a good idea to have compatibility for the baseline between Linux and Windows, but it wouldn't work completely. Sometimes more things are different. Here's an example of an error message between Windows and Linux (the offset number is different because there are more characters on Windows):

		-
			message: """
				#^PHPDoc tag @param has invalid value \\(
				           \\$object\\)\\: Unexpected token "\\\\n\\\\t \\* ", expected type at offset 110 on line 4$#
			"""
			count: 1
			path: UnixNewlines.php

		-
			message: """
				#^PHPDoc tag @param has invalid value \\(\r
				           \\$object\\)\\: Unexpected token "\\\\r\\\\n\\\\t \\* ", expected type at offset 113 on line 4$#
			"""
			count: 1
			path: WindowsNewlines.php

So at this point I'm afraid to change anything because it could break someone's workflow. People who have mixed environment like that already solve it somehow themselves.