8000 [Yaml] fix for wrong parsing functionality on some indentation cases by dekelev · Pull Request #8100 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Yaml] fix for wrong parsing functionality on some indentation cases #8100

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

Closed
wants to merge 1 commit into from
Closed

Conversation

dekelev
Copy link
@dekelev dekelev commented May 19, 2013

No description provided.

I have problems at the moments setting up PHPUnit testing environment, so any help with testing it would be appreciated.
@indeyets
Copy link

@dekelev is your "will work" example valid? I can't parse it in my head, as you inject a sequence in the middle of a mapping.

"won't work" example is another thing — sequence is a value, corresponding to key a in mapping

@dekelev
Copy link
Author
dekelev commented May 20, 2013

Because YAML depends on space indentation, "- b: c" line will always be a sibling to key "a", and not consider its mapped value.
For it to be consider as value of "a", "- b: c " line should be indented at least one space more.

And regards to the empty value:
null is a "no value" value.

#7274
http://yaml.org/spec/history/2001-08-01.html

So "a" key has a value, NULL value, because next line indentation is equal to this line which excludes it from mapping it as "a" value.

@indeyets
Copy link

Indentation is not the only mean for key/value distinction. see this http://www.yaml.org/spec/1.2/spec.html#id2772312

@dekelev
Copy link
Author
dekelev commented May 20, 2013

Right, but in these examples there is no other means of key/value distinction. only key/value mapping using colon+indentation OR colon+inline value

@indeyets
Copy link

"won't work" example is very similar to example from spec and unambiguously implies the following structure:

{test: {a: [{b: c}]}}

@dekelev
Copy link
Author
dekelev commented May 20, 2013
---
test:
  a:
  - b: c

should implies

{test: {a: null, [{b: c}]}}

while

---
test:
  a:
   - b: c

should implies

{test: {a: [{b: c}]}}

@stof
Copy link
Member
stof commented May 20, 2013

@dekelev Tests are missing for your fix.

and please update the description with the PR summary

@indeyets
Copy link

@dekelev {test: {a: null, [{b: c}]}} is NOT a valid data structure. YAML spec definitely means {test: {a: [{b: c}]}} in both cases. I already provided link to example in spec which supports my point of view.

@stof
Copy link
Member
stof commented May 20, 2013

FYI, both http://yamllint.com/ (using Ruby) and http://yaml-online-parser.appspot.com/ (using pyyaml in Python) are parsing it in the way described by @indeyets in the previous comment.

@dekelev
Copy link
Author
dekelev commented May 20, 2013

@indeyets @stof you are probably right here
In any case, this is an issue required a fix instead of throwing ParseException.
Will get to it later

@indeyets
Copy link

@dekelev yup. see #8076
I filed #8093 separately, as symptoms differ.

it's good if those are fixed by single commit, but I decided that it makes sense to track them separately

@dekelev
Copy link
Author
dekelev commented May 20, 2013

thanks @indeyets, I'll try handle both cases in next commit.

@lavoiesl
Copy link
Contributor

I dont get it, {test: {a: [{b: c}]}} should be :

test:
  a:
    - b: c

and this should not even be valid:

test:
  a:
  - b: c

it would indeed correspond to {test: {a: null, [{b: c}]}}, but it makes no sense because you are mixing numerical indices and keys

From what I understand, this PR tries to let the parser be more forgiving while the input should have been correct in the first place.

@indeyets
Copy link

@lavoiesl please read the spec and previous comments. It is a valid syntax

@cordoval
Copy link
Contributor
cordoval commented Dec 7, 2013

just in case you guys are not aware #8562
I personally think the yaml component and the Parse class is one of the most needing love. It does the job for symfony and that was enough back at the time but if you are trying to parse yaml independently and use all spec from yaml then you will find several weaknesses. i was thinking working on this but the constraints of "not a lot of code" discouraged me. If i were to implement this parser again then i would port this stdlib from ruby https://github.com/tenderlove/psych/blob/master/test/psych/test_parser.rb not sure if still at the time capable of doing successfully or quick enough. But it is a hint. Let's relate the tickets regarding these yaml limitations at least so we don't multiply tickets.

👶

@fabpot
Copy link
Member
fabpot commented Dec 29, 2013

Closing this one as the Symfony YAML component has never been about implementing the whole YAML spec, but just the most-commonly used subset for configuration files. Doing any changes must come with a large number of unit tests to be sure than nothing breaks. This change does break things, so it cannot be merged anyway. Feel free to reopen with updated unit tests though.

@fabpot fabpot closed this Dec 29, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0