To be fair, it only happens here because this is a C-style API that was
converted to Go but keeping its general shape. The proper fix, to be
done eventually, is to replace all these boolean error flags by proper
error types.

Fixes #665

It's curious choice from the underlying API to generally return a
positive result on success, but on this case return true in an error
scenario.

Fixes #666

This addresses a number of related issues on how merge tags
were handled, most notably the case of nested mappings being
merged instead of the outermost value being used as-is.

Closes: #818 #826

A null value in v3 is considered a request to maintain the default
untouched. If the value being decoded into is a map and there's no
prior value for the field, a new key will be added with the zero
map value type as its value.

This makes it behave a bit closer to the original PR from Felix as well.

When a comment is indented, it may be visually associated as a header
of the following line instead of being a footer of the former, even
if there is a line break. For example:

key:
    # Comment

    - Underlying value

Replace Travis by Github Actions.

Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>

Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>

Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>

This change allows the following document to correctly roundtrip:

  foo:
    # Head comment of following map
    - # Head comment of bar
      bar: # Line comment of bar
        baz # Line comment of baz

The logic for indentation was also tuned so it's again more regular.

This should help with cases described in #554.

Sequences used to be slightly different, and v3 made it slightly
different in a slightly different way, and that's all slightly bad.
All gone now. Sequences indent just like everything else.

We adhere to the YAML 1.2 for input, but only parsing "on", "off", and
friends, as strings rather than bools. When outputting however we will
ensure that we quote these cases. Failure to do so forces makes the
output ambiguous if it then to be parsed by a YAML 1.2 parser.

Message from original commit (53403b58):

This change introduces an index to lookup token numbers referenced by simple_keys in O(1),
thus significantly reducing the performance impact of certain abusively constructed snippets.

When we build up the simple_keys stack, we count on the (formerly named) staleness check to
catch errors where a simple key is required but would be > 1024 chars or span lines. The previous
simplification that searches the stack from the top can go 1024 keys deep before finding a "stale"
key and stopping. I added a test that shows that this consumes ~3s per 1MB of document size.

This was broken when special casing to handle #533.

Also applied as 1f64d615 in v2.

Cases like this are now handled properly:

  # Header for the whole list
  - # Header for some data
    - Some data

Fixes #533.

This should simplify the logic and significantly improve
performance in edge cases as found and reported on #537
by CJ Cullen.

Add good testing to make sure there's nothing else lurking.

This is a forward port of v2 commit f221b843 by Jordan Liggitt.