Add unmaintained unsafe-libyaml & serde_yaml

[jayvdb]

Closes #2132

[jayvdb]

pinging maintainers of crates listed as alternatives, so they can comment on the descriptions / appropriateness of these recommendations:
@romnn , @bourumir-wyngs , @KmolYuan , @simonask , @Ethiraric , @g-plane , @elioseverojunior , @ clockworkengineer & @oovm

[bourumir-wyngs]

I suggest to replace this by

 [`serde-saphyr`](https://crates.io/crates/serde-saphyr) - Implementation of YAML for serde framework, replaces unsafe-libyaml by saphyr-parser.

While the library is relatively young, "incomplete" implies that this is a stub that lacks all the necessary functionality. This is not the case.

[jayvdb]

@bourumir-wyngs I am not happy with that alternative you provide, but I do understand what you are getting at.

The main point that must be conveyed is that serde-saphyr is not a complete implementation of YAML 1.2, because saphyr-parser is still incomplete wrt YAML 1.2 spec. Very incomplete. I have lots of types of data structures that worked with serde_yaml that fail inside saphyr-parser. It did work for a few simpler data structures, and I adopted it for those. But it is not nearly as good at yaml-spanned, and it is roughly on par with serde_yaml2 based on my usage.

To be honest, I am not sure how complete serde-saphyr is wrt to the serde framework. i.e. which issues are due to serde-saphyr immaturity vs problems it inherits from saphyr-parser and cant fix until saphyr-parser improves. It is a bit difficult for an outside observer to easily identify which is the cause of the problems. That said, from what I saw, there is a bit of both to blame for the problems I saw trying to migrate a very large commercial codebase to serde-saphyr.

[bourumir-wyngs]

While saphyr-parser needs more work, I do not see where else would be the way to go. yaml-spanned you talk about uses internally libyaml-safer that is, again, the fork of the same unsafe-libyaml. Having cascades of unsafe there is fundamentally a problem, memory safety is on the main Rust's selling points.

Serde-saphyr currently has 618 passing tests, many of which were ported from the yaml-test-suite (those with a y_prefix), and also quite many from serde-yaml. If you would share at least some of these "lots" structures that do not work, I would be thankful. yaml-rust2 (from whom saphyr-parser is the fork with modern features) has 19,601,133 downloads to date so I think works for some.

[jayvdb]

libyaml-safer does not use unsafe. https://github.com/simonask/libyaml-safer/blob/c09b7a24554171e32fa958042304af0f4cf4e203/src/lib.rs#L22

[jayvdb]

https://github.com/saphyr-rs/saphyr/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen lists the many fundamental issues with saphyr-parser wrt YAML. And I ran into many of those. It changes the data-type of incoming data. And that blows up your serde layer on top of it in weird ways.

[simonask]

I consider libyaml-safer "complete", in the sense that it is a faithful (bug-for-bug) port, but I'm also unfortunately not able to devote enough time to actually keep it updated with hypothetical new bugfixes in libyaml (or the unmaintained machine-translated Rust version, unsafe-libyaml).

That's a very precarious state for it to be in, so I wouldn't consider it advisable to recommend it as an alternative at this stage.

If anyone wants to pick it up where I left off, I'm more than happy to provide guidance!

[jayvdb]

@simonask , there wont be any updates from archived repo unsafe-libyaml, and https://github.com/yaml/libyaml is moribund - it has many simple PRs not getting merged for years, including one of mine. I am happy to help with maintenance of your repo. maybe @romnn could also help, given he built yaml-spanned on top of it?