More Rust idioms

[Plecra]

It's common (almost universal~) for Rust projects to use cargo fmt and cargo clippy to keep code predictable and easier to collaborate on.

[slightknack]

I generally like cargo fmt, however one thing I'm not a fan of is the fact that it can't align match arms (IIRC):

match x {
    Some(y) => y,
    None    => 0,
}

As Passerine matches on enums a lot while compiling ASTs, I'd prefer rustfmt to do this. This is basically the only reason I haven't decided to use rustfmt yet.

As for clippy; I agree. Perhaps putting in a PR that enables clippy and ensures all the existing code is clippy-friendly might be a good first contribution.

[Plecra]

I'll pop this here in case there's any movement rust-lang/rustfmt#894

[twe4ked]

Looks like putting #[rustfmt::skip] on the match works (now?):

impl Display for Data {
    /// Displays some Passerine Data in a pretty manner, as if it were printed to console.
    fn fmt(&self, f: &mut Formatter<'_>) -> Result {
        #[rustfmt::skip]
        match self {
            Data::Heaped(_)   => unreachable!("Can not display heaped data"),
            Data::NotInit     => unreachable!("found uninitialized data on top of stack"),
            Data::Real(n)     => write!(f, "{}", n),
            Data::Integer(n)  => write!(f, "{}", n),
            Data::Boolean(b)  => write!(f, "{}", if *b { "true" } else { "false" }),
            Data::String(s)   => write!(f, "{}", s),
            Data::Lambda(_)   => unreachable!("Can not display naked functions"),
            Data::Closure(c)  => write!(f, "Function ~ {}", c.id),
            Data::Kind(_)     => unreachable!("Can not display naked labels"),
            Data::Label(n, v) => write!(f, "{} {}", n, v),
            Data::Unit        => write!(f, "()"),
            Data::Tuple(t)    => write!(f, "({})", t.iter()
                .map(|i| format!("{}", i))
                .collect::<Vec<String>>()
                .join(", ")
            ),
        }
    }
}

How do you feel about that as a compromise?

[slightknack]

I think that would be a reasonable compromise! If you want to put in a PR annotating (but not running rustfmt on) all match statements, that would be a great first contribution! (There are a healthy number of match statements (~24) to annotate, though.) If not, I can do that when I get the time, no worries.

…

On Tue, Aug 3, 2021 at 5:34 AM Odin Dutton ***@***.***> wrote: Looks like putting #[rustfmt::skip] on the match works (now?): impl Display for Data { /// Displays some Passerine Data in a pretty manner, as if it were printed to console. fn fmt(&self, f: &mut Formatter<'_>) -> Result { #[rustfmt::skip] match self { Data::Heaped(_) => unreachable!("Can not display heaped data"), Data::NotInit => unreachable!("found uninitialized data on top of stack"), Data::Real(n) => write!(f, "{}", n), Data::Integer(n) => write!(f, "{}", n), Data::Boolean(b) => write!(f, "{}", if *b { "true" } else { "false" }), Data::String(s) => write!(f, "{}", s), Data::Lambda(_) => unreachable!("Can not display naked functions"), Data::Closure(c) => write!(f, "Function ~ {}", c.id), Data::Kind(_) => unreachable!("Can not display naked labels"), Data::Label(n, v) => write!(f, "{} {}", n, v), Data::Unit => write!(f, "()"), Data::Tuple(t) => write!(f, "({})", t.iter() .map(|i| format!("{}", i)) .collect::<Vec<String>>() .join(", ") ), } } } How do you feel about that as a compromise? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANCIUGQ7ND7R5WZNAARQHQDT25PWFANCNFSM43AAVMRA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[twe4ked]

Sweet! I took a crack at it here: #57

[slightknack]

Appreciated! I have a rustfmt.toml and GitHub Action ready to go. btw, there was a CI build issue due using #[...] in an experimental position, up to you as to how we should proceed 😄. Thanks again for putting this PR in.

[slightknack]

I've just decided to go with rustfmt, imperfect as it may be. With @Kethku's clippy fixes from a while back, I think I can say that the usage of Rust idioms in this project has improved significantly. The bytecode verification function and the eventual move towards a strongly-typed type system should alleviate most of the unsafe concerns.