Silence clippy lints in ascent!{ … } & ascent_run!{ … } macro expansions

[regexident]

Given a program

# Cargo.toml

[dependencies]
ascent = "0.4.0"

// main.rs

use ascent::ascent;

ascent! {
   relation edge(i32, i32);
   relation path(i32, i32);

   path(x, y) <-- edge(x, y);
   path(x, z) <-- edge(x, y), path(y, z);
}

fn main() {
    let mut prog = AscentProgram {
        edge: vec![(1, 2), (2, 3)],
        ..Default::default()
    };
    prog.run();
    println!("path: {:?}", prog.path);
}

Running cargo clippy results in a couple of clippy warnings:

• clippy::clone_on_copy
• clippy::let_unit_value

Full terminal output

warning: using `clone` on type `i32` which implements the `Copy` trait
 --> src/main.rs:5:13
  |
5 |    relation path(i32, i32);
  |             ^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#clone_on_copy
  = note: `#[warn(clippy::clone_on_copy)]` on by default
help: try removing the `clone` call
  |
5 ~    relation ascent! {
6 +    relation edge(i32, i32);
7 +    relation path(i32, i32);
8 + 
9 +    path(x, y) <-- edge(x, y);
10+    path(x, z) <-- edge(x, y), path(y, z);
11~ }(i32, i32);
  |

warning: using `clone` on type `i32` which implements the `Copy` trait
 --> src/main.rs:8:36
  |
8 |    path(x, z) <-- edge(x, y), path(y, z);
  |                                    ^ help: try dereferencing it: `*y`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#clone_on_copy

warning: using `clone` on type `i32` which implements the `Copy` trait
 --> src/main.rs:8:27
  |
8 |    path(x, z) <-- edge(x, y), path(y, z);
  |                           ^ help: try dereferencing it: `*y`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#clone_on_copy

warning: using `clone` on type `i32` which implements the `Copy` trait
 --> src/main.rs:4:13
  |
4 |    relation edge(i32, i32);
  |             ^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#clone_on_copy
help: try removing the `clone` call
  |
4 ~    relation ascent! {
5 +    relation edge(i32, i32);
6 +    relation path(i32, i32);
7 + 
8 +    path(x, y) <-- edge(x, y);
9 +    path(x, z) <-- edge(x, y), path(y, z);
10~ }(i32, i32);
  |

warning: this let-binding has unit value
 --> src/main.rs:4:13
  |
4 |    relation edge(i32, i32);
  |             ^^^^ help: omit the `let` binding: `edge;`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_unit_value
  = note: `#[warn(clippy::let_unit_value)]` on by default

warning: `graph_queries` (bin "graph_queries") generated 5 warnings (run `cargo clippy --fix --bin "graph_queries"` to apply 5 suggestions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s

[regexident]

@s-arash if applying #![allow(clippy::all)] to ascent's generated code by default is something you're hesitant about for development reasons (which is totally fair!), then here is an alternative that might be worth considering:

Allow for and detect attributes on the optional struct Program; declaration and then copy those over to the generated type and its impls.

From a user's perspective it would of course be preferable if warnings —especially those that can't actually be fixed by the user themselves— were to not get emitted in the first place, but this seems like it might be a reasonable compromise?

With ascent_run! you can already silence warnings by doing this (due to a single block item getting generated by ascent_run!):

#[allow(clippy::all)]
let res = ascent_run!{
   struct Program;

   // ...
};

The following however does not work, due to multiple items (struct + impl) getting generated by ascent!:

#[allow(clippy::all)]
ascent! {
   struct Program;

   // ...
};

Hence the need for a workaround, for which I would thus like to propose the following:

ascent! {
   #![allow(clippy::all)] // 👈🏻
   struct Program;

   // ...
};

[regexident]

@s-arash if I was to open a PR for the approach outlined in my last comment, would you in principle be open for such a "feature"? Being able to pass attributes to the struct definition (and/or its impls) seems quite useful far beyond silencing o clippy warnings.