rustfmt-formattable syntax? #35

New issue

Open

opened 2020-07-08 21:23:19 -05:00 by coolreader18 · 5 comments

coolreader18 commented

2020-07-08 21:23:19 -05:00

(Migrated from github.com)

I'm aware how minimal and stable this crate is and has been for a long time, but something that's always put me off from using it (usually in favor of manual #[cfg] attributes) is how its syntax is completely unfamiliar to rustfmt, and therefore any expressions or items inside of a cfg_if! block can't get the advantages that rustfmt brings.

// stays as is when `cargo fmt` is run
cfg_if! {
    if #[cfg(foobar)] {
        fn baz() { qux();   flop()
        }
    }
    else {
        fn bar() {
        }
    }
}

Was there a reason that you didn't choose a more traditional/valid rust syntax for the macro? e.g.

cfg_if!(if cfg!(foobar) {
    fn baz() {
        qux();
        flop()
    }
} else {
    fn bar() {}
});

I'm aware that rustfmt wasn't as popular/well-integrated in 2017, but I feel like a syntax like this would greatly improve the ergonomics of this crate.

(feel free to ignore, I was just surprised that there wasn't an issue about this already)

I'm aware how minimal and stable this crate is and has been for a long time, but something that's always put me off from using it (usually in favor of manual `#[cfg]` attributes) is how its syntax is completely unfamiliar to rustfmt, and therefore any expressions or items inside of a `cfg_if!` block can't get the advantages that rustfmt brings. ```rust // stays as is when `cargo fmt` is run cfg_if! { if #[cfg(foobar)] { fn baz() { qux(); flop() } } else { fn bar() { } } } ``` Was there a reason that you didn't choose a more traditional/valid rust syntax for the macro? e.g. ```rust cfg_if!(if cfg!(foobar) { fn baz() { qux(); flop() } } else { fn bar() {} }); ``` I'm aware that rustfmt wasn't as popular/well-integrated in 2017, but I feel like a syntax like this would greatly improve the ergonomics of this crate. (feel free to ignore, I was just surprised that there wasn't an issue about this already)

alexcrichton commented

2020-07-09 08:58:18 -05:00

(Migrated from github.com)

I chose to use #[cfg] instead of cfg! because cfg! already exists but behaves differently than this crate. It's true that when this was created rustfmt didn't exist, but I would indeed be interested if there's a way to get rustfmt to look at code inside the macro and format it. I don't know what heuristics rustfmt has, however.

I chose to use `#[cfg]` instead of `cfg!` because `cfg!` already exists but behaves differently than this crate. It's true that when this was created rustfmt didn't exist, but I would indeed be interested if there's a way to get rustfmt to look at code inside the macro and format it. I don't know what heuristics rustfmt has, however.

👍 1

calebcartwright commented

2021-10-04 18:31:21 -05:00

(Migrated from github.com)

We don't really have the ability to format anything that's contained with any macro call using brace delimiters, so a change to cfg! isn't going to do anything for rustfmt.

cfg_if is actually already one of the special case scenarios where we do peek inside to look for any out-of-line mods that are imported and we do format the associated files for those mods, but don't touch the inline args to the mac call.

Our ability to format the out-of-line mods is heavily predicated on the current syntax, so the only immediate impact of from #[cfg] to cfg! would actually be to break the current ability to format those mods.

We don't really have the ability to format anything that's contained with any macro call using brace delimiters, so a change to `cfg!` isn't going to do anything for rustfmt. `cfg_if` is actually already one of the special case scenarios where we do peek inside to look for any out-of-line mods that are imported and we _do_ format the associated files for those mods, but don't touch the inline args to the mac call. Our ability to format the out-of-line mods is heavily predicated on the current syntax, so the only immediate impact of from `#[cfg]` to `cfg!` would actually be to break the current ability to format those mods.

raviqqe commented

2025-01-22 18:46:12 -06:00

(Migrated from github.com)

I just realized that this is possible while also solving #43. I implemented the macros in the cfg-elif crate. For items, you always need to use parenthesis for macro calls like item::cfg!().

use cfg_elif::item;

item::cfg!(if (feature == "foo") {
    type Foo = usize;
} else if (target_pointer_width != "64") {
    type Foo = isize;
} else if ((target_family == "unix") && (feature == "bar")) {
    type Foo = i32;
} else if ((feature == "baz") || (target_os == "freebsd")) {
    type Foo = i64;
} else if (!(panic == "unwind")) {
    type Foo = i128;
} else {
    type Foo = f64;
});

Will you accept a PR for this when I make one? Or, do you think this is to hacky for a repository under rust-lang?

I just realized that this is possible while also solving #43. I implemented the macros in [the `cfg-elif` crate](https://github.com/raviqqe/cfg-exif). For items, you always need to use parenthesis for macro calls like `item::cfg!()`. ```rust use cfg_elif::item; item::cfg!(if (feature == "foo") { type Foo = usize; } else if (target_pointer_width != "64") { type Foo = isize; } else if ((target_family == "unix") && (feature == "bar")) { type Foo = i32; } else if ((feature == "baz") || (target_os == "freebsd")) { type Foo = i64; } else if (!(panic == "unwind")) { type Foo = i128; } else { type Foo = f64; }); ``` Will you accept a PR for this when I make one? Or, do you think this is to hacky for a repository under `rust-lang`?

ChrisDenton commented

2025-01-22 18:50:26 -06:00

(Migrated from github.com)

It's likely development efforts are going to be focused on getting match_cfg ready for stabilization, which will entirely replace the need for this crate.

It's likely development efforts are going to be focused on getting [`match_cfg`](https://github.com/rust-lang/rust/issues/115585) ready for stabilization, which will entirely replace the need for this crate.

👍 1

raviqqe commented

2025-01-22 18:54:34 -06:00

(Migrated from github.com)