Some values are getting parsed incorrectly

[panicbit]

Failing examples:

{foo: 'bar'}

{foo: true}

{foo: false}

{foo: null}

The values are all getting handled as unquoted strings (for different underlying reasons) and thus wrongly consume the closing }.

[Denys Séguret]

Thanks. Do you have unit tests ? What types did you deserialize into ?

[panicbit]

Check out the PR #4 , it add tests for the failing cases.
This issue only happens if deserializing null or bools into to a type that calls deserialize_any.
For single quoted strings it shouldn't matter.

[panicbit]

Well nvm, I failed to commit the new test file for null and bool.

[panicbit]

I added the missing test

deser-hjson/tests/objects.rs

Lines 5 to 16 in fb4c368

 /// check we fixed the bug #3 
 #[test] 
 fn test_member_values() { 
     // These values were problematic 
     deser_hjson::from_str::<Value>("{foo:null}").unwrap(); 
     deser_hjson::from_str::<Value>("{foo:false}").unwrap(); 
     deser_hjson::from_str::<Value>("{foo:true}").unwrap(); 
     deser_hjson::from_str::<Value>("{foo:'bar'}").unwrap(); 
     // Also check some already working values 
     deser_hjson::from_str::<Value>(r#"{foo:"bar"}"#).unwrap(); 
     deser_hjson::from_str::<Value>("{foo:42}").unwrap(); 
 } 

[Denys Séguret]

I've just had a second look at the Hjson spec on quoteless strings:

7 # minutes is the number 7 followed by a comment

There's probably a problem too for numbers in deser_hjson.

I'll have a deep look at your PR and test units as soon as possible.

[panicbit]

Sidenote:
I just saw your Q&A on Why only a derive-based deserializer?.
While I agree that guessing types can be terrible (I ran into confusion myself whith YAML and Kaitai Struct), I think parsing should either succeed completely or fail early with an appropriate error message.
If you want to explicitly want to reject this usecase, you could probably stub out the deserialize_any implementations, however, this will probably also block valid usecases like serde(flatten).
So overall, I think it is a good suggestion to avoid deserializing into generic types if possible, but it's probably not something that can be enforced reasonably.

[Denys Séguret]

There are grey areas I'd like to handle as well as possible, most especially untagged enums (example in tests). Those ones are very convenient in conf and are rarely ambiguous as soon as you advise users to avoid closing braces on the same lines.

[panicbit]

Just why did they have to add unquoted strings (that can include }, ], or ,) 😞

[Denys Séguret]

I've added a few more tests. I'll probably do a release soon enough. If you do external tests, please tell me.

[panicbit]

Seems like this isn't fully fixed yet.
I'm running into

Error: ExpectedMapColon at 1:535 at "isAvailable:tru"

and this when deserializing into a struct with derived Deserialize.
However, this error message is already more helpful than in the 1.0.0 version, because there the error is:

Error: Eof at 1:5827 at ""

I will investigate this further.

PS: Deserializing into a generic Value type did work properly so, so the other deserialize functions probably need a similar treatment as deserialize_any.

[Denys Séguret]

Can you build a test unit ? Or give me your test file ?

[Denys Séguret]

Side note: It's usually easier to discuss on miaou.