pretty printing regression

[m4b]

I'm seeing a pretty printing regression in 0.6 from 0.5; looks to be in nested arrays and structs?

E.g., seeing this in diffs now:

+                ),            ],
+        )),    ],

I believe a newline is missing after the ),, since adding a newline after yields the expected pretty printed string:

                ),
            ],
        )),
    ],

[kvark]

@Plecra could be related to #206 ?

[Plecra]

Probably, yup. Someone will need to check the diff for a logic error in the tuple generator, and add a test for it.

[Plecra]

@m4b, would you be able to provide a minimal reproduction please? I wasn't able to get it to misbehave locally.

[m4b]

Sure, this repro's for me:

(
    name: "foo",
    stuff: [
        Group(
            (
                name: "baz",
                group: "baz_group",
                instances: [
                    (
                        name: Some("2-2"),
                    ),
                ],
            ),
        ),
    ],
)

Repro code, if you save above as file, read it, then write it out, it should have the issue:

use serde::{Deserialize, Serialize};

use std::io::{Read, Write};

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct Foo {
    pub name: Option<String>,
}

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct StuffInner {
    pub name: String,
    pub group: String,
    pub instances: Vec<Foo>,
}

#[derive(Debug, Serialize, Deserialize, Clone)]
pub enum Stuff {
    Group(StuffInner),
}

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct Top {
    name: String,
    stuff: Vec<Stuff>,
}

fn main() {
    let args: Vec<String> = std::env::args().collect();
    let mut f = std::fs::File::open(&args[1]).unwrap();
    let r: Top = ron::de::from_reader(f).unwrap();
    let pretty = ron::ser::PrettyConfig::default();
    let ron = ron::ser::to_string_pretty(&r, pretty).unwrap();
    let mut f = std::fs::File::create(&format!("fmt.{}", &args[1])).unwrap();
    f.write_all(ron.as_bytes()).unwrap();
}

[m4b]

@Plecra you’re able to repro with above right ?

[Plecra]

Nope, I actually can't. This test passes on master, just as it does on cea5d78. I'm not sure what code could've originally generated your .ron data, and I'm not seeing any problem with newlines either.

use ron::ser::{to_string_pretty, PrettyConfig};

#[test]
fn small_array() {
    use serde::{Deserialize, Serialize};

    use std::io::{Read, Write};

    #[derive(Debug, Serialize, Deserialize, Clone)]
    pub struct Foo {
        pub name: Option<String>,
    }

    #[derive(Debug, Serialize, Deserialize, Clone)]
    pub struct StuffInner {
        pub name: String,
        pub group: String,
        pub instances: Vec<Foo>,
    }

    #[derive(Debug, Serialize, Deserialize, Clone)]
    pub enum Stuff {
        Group(StuffInner),
    }

    #[derive(Debug, Serialize, Deserialize, Clone)]
    pub struct Top {
        name: String,
        stuff: Vec<Stuff>,
    }
    assert_eq!(
        to_string_pretty(&Top {
            name: "foo".into(),
            stuff: vec![
                Stuff::Group(StuffInner {
                    name: "baz".into(),
                    group: "baz_group".into(),
                    instances: vec![
                        Foo {
                            name: Some("2-2".into())
                        }
                    ]
                })
            ]
        }, PrettyConfig::new().with_new_line("\n".to_string())
    ).unwrap(),
        r#"(
    name: "foo",
    stuff: [
        Group((
            name: "baz",
            group: "baz_group",
            instances: [
                (
                    name: Some("2-2"),
                ),
            ],
        )),
    ],
)"#);
}

Edit: @kvark, I'm happy to look into this when there's a failing test for me to fix, but I won't be investigating the issue any more

[dmit]

This is #240, which is fixed in master, but not in the most recent published crate version (0.6.0).

[kvark]

Ah, that makes sense! We need another PR with the same changes but against our v0.6 branch. A separate commit would need to be added to bump the patch version and add a short changelog entry.

[torkleyy]

Can this be closed?

[m4b]

The issue still exists on published 0.6 crate... can a new 0.7 be published if backporting is hard? It’s quite annoying, I have checked in ron files and the diff from this is enormous...

[kvark]

Looks like I forgot to publish the fix. Sorry about it! v0.6.1 is now up.

[m4b]

Thank you ! ❤️