Trailing newline in a multi-line string is incorrectly expected to be trimmed

[Daniil Baturin]

The tests include the following expectation:

FAIL valid/string-nl
     Values for key 'nl_end' don't match:
       Expected:     value
     
       Your encoder: value\n

     input sent to parser-cmd:
       nl_mid = "val\nue"
       nl_end = """value\n"""

That goes against the spec that requires that the leading newline be trimmed, but expressly states that all other whitespace should be kept:

Multi-line basic strings are surrounded by three quotation marks on each side and allow newlines.
A newline immediately following the opening delimiter will be trimmed.
All other whitespace and newline characters remain intact.

[Martin Tournoij]

The JSON file has this as the expected value:

value\n

Where \n is a newline. It's not removed in the expected value.

Not sure, but I think what's going on is that your encoder returns the text \n rather than an actual newline, maybe it's not parsing the \n escape sequence correctly from:

nl_end = """value\n"""

The error output on this could be clearer btw.

[Daniil Baturin]

The encoder interprets \n as a newline. When the string is passed to a JSON encoder for printing, a newline inside that string is escaped and printed as \n of course.

Here's a view from inside the WIP library:

utop # Otoml.Parser.from_string " nl_end = \"\"\"value\n\"\"\" " |> 
  Result.get_ok |> 
  (fun t -> Otoml.find Otoml.get_string t ["nl_end"]) |> print_endline ;;
value

- : unit = ()

It also looks like the JSON with that expectation does have a newline:

  "nl_end": {
    "type": "string",
    "value": "value\n"
  },

so the issue is likely in the test runner.

[Martin Tournoij]

I'm not really familiar with OCAML, and I can't really interpret that example.

However, if I create a "fake" decoder which sends this (note the \\n instead of \n):

"nl_end": {
    "type": "string",
    "value": "value\\n"
  },

Then I get the same error as you have:

$ toml-test ./fake -run valid/string-nl
FAIL valid/string-nl
     Values for key 'nl_end' don't match:
       Expected:     value

       Your encoder: value\n

What is the full error output in your case (specifically, the "output from parser-cmd" section)?

It's possible there is an error in the test runner, but as far as I can see it doesn't trim or modify strings at all: just if want != have.

[Daniil Baturin]

I'm starting to think that it's a problem on my end in the end. I'll do more testing and close the issue if it turns out to be the case, or get back with debugging data if it doesn't.

[Daniil Baturin]

It was a problem on my end, though a relatively subtle one... I shouldn't have stayed up so long. ;)

[Martin Tournoij]

Coolio; no worries :-)