Styling of Rust Frontmatter

[epage]

RFC 3503 adds the concept of a frontmatter to rust for the sake of RFC 3502: cargo-script.

Ideally, before stabilization, we decide on the style and get support for it.

[epage]

Question 1: Should rustfmt insert a blank line before frontmatters?

Compare:

#!/usr/bin/env cargo
---
[dependencies]
clap = { version = "4.2", features = ["derive"] }
---

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

#!/usr/bin/env cargo

---
[dependencies]
clap = { version = "4.2", features = ["derive"] }
---

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

[epage]

Question 2: Should rustfmt remove extraneous newlines before or after frontmatter?

Compare:

#!/usr/bin/env cargo
---
[dependencies]
clap = { version = "4.2", features = ["derive"] }
---

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

#!/usr/bin/env cargo



---
[dependencies]
clap = { version = "4.2", features = ["derive"] }
---




use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

[epage]

Question 3: Should rustfmt remove extraneous spaces on the infostring

Compare:

#!/usr/bin/env cargo
---cargo
[dependencies]
clap = { version = "4.2", features = ["derive"] }
---

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

#!/usr/bin/env cargo
---    cargo     
[dependencies]
clap = { version = "4.2", features = ["derive"] }
---

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

[epage]

Question 4: Should rustfmt coerce to the minimum number of dashes

Compare:

#!/usr/bin/env cargo
---
[dependencies]
clap = { version = "4.2", features = ["derive"] }
---

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

#!/usr/bin/env cargo
-----------------------
[dependencies]
clap = { version = "4.2", features = ["derive"] }
-----------------------

use clap::Parser;

#[derive(Parser, Debug)]
#[clap(version)]
struct Args {
    #[clap(short, long, help = "Path to config")]
    config: Option<std::path::PathBuf>,
}

fn main() {
    let args = Args::parse();
    println!("{:?}", args);
}

[epage]

There is also the question of whether this issue, #4091, or another issue should be responsible for processing the embedded Cargo.toml.

[epage]

Also, are there any expectations from rustc's lexer that need to be kept in mind for rustfmt? My initial assumption is to eat the frontmatter like we eat shebangs but I'm assuming rustfmt uses the lexer and that that might not work for you.

[ytmimi]

Also, are there any expectations from rustc's lexer that need to be kept in mind for rustfmt? My initial assumption is to eat the frontmatter like we eat shebangs but I'm assuming rustfmt uses the lexer and that that might not work for you.

rustfmt uses the rustc parser. Is it possible to represent the frontmatter in the AST? That would be idea for formatting.