Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix libyaml 0.2.1 incompatibility #6287

Merged
merged 1 commit into from Jun 29, 2018

Conversation

straight-shoota
Copy link
Member

@straight-shoota straight-shoota commented Jun 28, 2018

Fixes #6283

libyaml 0.2.1 removed the errorneously written document end marker (...) after some scalars in root context (see yaml/libyaml#18).
Earlier libyaml releases still write the document end marker and both older and newer releases need to be supported.

This implements modifying the expected value depending on the version of libyaml as suggested in #6285 (comment).

I don't think it is feasible to implement the fix for libyaml < 0.2.1 in Crystal as suggested in #6285 (comment). This would make YAML always behave the same, whatever version of libyaml it is used with. But it would require rewriting the output written to the builder IO by libyaml. Since the impact is pretty small - YAML documents consisting of only a scalar are pretty rare outside of test suites.

libyaml 0.2.1 removed the errorneously written document end marker (`...`) after some scalars in root context (see yaml/libyaml#18).
Earlier libyaml releases still write the document end marker and this is hard to fix on Crystal's side. So we just ignore it and adopt the specs accordingly to coincide with the used libyaml version.
@bcardiff
Copy link
Member

SemanticVersion can be used in the spec probably. But LGTM.

It’s a pitty that then a guard would be needed on a new libyaml release to turn on the end of document again... Or maybe as times goes we can think that 0.2.1 is yanked.

@sdogruyol
Copy link
Member

One more reason to have our pure Crystal version of libyaml alternative in the future 👍

@straight-shoota
Copy link
Member Author

@bcardiff Why would we need to change on a new libyaml release? I don't expect it to switch back the previous, incorrect behaviour. It was a bug fix. Our specs now take the bug into account if libyaml < 0.2.1

@bcardiff
Copy link
Member

Oh, i read it wrong. I thought it was a regression introduced in 0.2.1.

@bcardiff bcardiff merged commit 9418892 into crystal-lang:master Jun 29, 2018
@straight-shoota straight-shoota deleted the jm/fix/libyaml-0.2.1 branch June 29, 2018 07:47
@bcardiff bcardiff added this to the Next milestone Jun 29, 2018
@RX14 RX14 modified the milestones: Next, 0.26.0 Jul 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

libyaml 0.2.1 breaks YAML builder
4 participants