Example trigger needless_arbitrary_self_type clippy lint

[Cyrix126]

Situation / Reproduction

Running the example from https://docs.rs/duplicate/latest/duplicate/#parameterized-substitution

struct VecWrap<T>(Vec<T>);

impl<T> VecWrap<T> {
  #[duplicate_item(
    method     reference(type);
    [get]      [& type];
    [get_mut]  [&mut type];
  )]
  pub fn method(self: reference([Self]), idx: usize) -> Option<reference([T])> {
    self.0.method(idx)
  }
}

Expected Behavior:

Find an example that doesn't trigger any clippy lint and produce the code displayed in the example:

struct VecWrap<T>(Vec<T>);

impl<T> VecWrap<T> {
  pub fn get(&self, idx: usize) -> Option<&T> {
    self.0.get(idx)
  }
  pub fn get_mut(&mut self, idx: usize) -> Option<&mut T> {
    self.0.get_mut(idx)
  }
}

Actual Behavior:

The following clippy lint is produced
https://rust-lang.github.io/rust-clippy/master/index.html#needless_arbitrary_self_type
Because it is producing

struct VecWrap<T>(Vec<T>);

impl<T> VecWrap<T> {
  pub fn get(self: &T, idx: usize) -> Option<&T> {
    self.0.get(idx)
  }
  pub fn get_mut(self: &mut T, idx: usize) -> Option<&mut T> {
    self.0.get_mut(idx)
  }
}

Affected Versions:

duplicate = "2.0.1"

Local Environment:

rustc 1.93.0-nightly (b33119ffd 2025-12-04)

Miscellaneous:

Obviously it is producing self: &T and self: &mut T instead of &self and &self mut T.

I tried editing the example to

use duplicate::duplicate_item;

struct VecWrap<T>(Vec<T>);

impl<T> VecWrap<T> {
    #[duplicate_item(
    method     reference(type);
    [get]      [& type];
    [get_mut]  [&mut type];
  )]
    pub fn method(reference([self]), idx: usize) -> Option<reference([T])> {
        self.0.method(idx)
    }
}

Although cargo expand produce a working result

#![feature(prelude_import)]
#[macro_use]
extern crate std;
#[prelude_import]
use std::prelude::rust_2024::*;
use duplicate::duplicate_item;
struct VecWrap<T>(Vec<T>);
impl<T> VecWrap<T> {
    pub fn get(&self, idx: usize) -> Option<&T> {
        self.0.get(idx)
    }
    pub fn get_mut(&mut self, idx: usize) -> Option<&mut T> {
        self.0.get_mut(idx)
    }
}

cargo check will report an error (on the non expanded code)

error: expected one of `:` or `|`, found `,`
  --> src/lib.rs:11:36
   |
11 |     pub fn method(reference([self]), idx: usize) -> Option<reference([T])> {
   |                                    ^ expected one of `:` or `|`

Of course, disabling the lint is possible, but I would prefer to find the right syntax to use.

[Emoun]

Thank you for opening the issue.

On a general note, avoiding clippy lint triggers in the documentation examples is not a priority. However, if we can find an example that doesn't trigger clippy lints, while still showing how the feature works, I can definitely accept the change.

Your fix to this example is not valid Rust code, because function parameters must either be self and its variants or a variable name, plus :, plus a type. And this has to be the case before macro expansion. The example is written in the only way (I know of) that is valid Rust before expansion, while changing the self ref type afterwards.
To fix this, I suspect the only way is to change the fundamental example (Vec wrapper) to something else that doesn't use self. All the examples in the section would need to be updated.

I will likely not change the example myself any time soon. However, I will keep the issue open and am willing to review any PR with a proposed alternate example.

[Cyrix126]

To fix this, I suspect the only way is to change the fundamental example (Vec wrapper) to something else that doesn't use self. All the examples in the section would need to be updated.

My title might be a misleading. I think finding a solution to have methods with self with this macro to result in the expanded code to follow recommended rust syntax is more important than just having the documentation example not emitting any lint warning.

That might be a tricky one to solve though.

[Emoun]

If I understand you correctly, you mean that you'd like there to be a way for duplicate_item to only produce code that doesn't trigger clippy lints?

I think that is outside the scope of this crate. The fact that the above code (and all code like it, changing the self ref type) triggers a clippy lint is not an issue with this crate, but with clippy/the user (not meant in a bad way). Having this crate fix that behind the scenes is not a good choice, in my opion. This could open up a whole game of wack-a-mole trying to find all lints that should be sanitized for. On top of that, what other crates should also get this treatment and where would it end? I would not want to open this can of worms.

There are workarounds:

1. Clippy has attributes to turn off lints for individual items. That could be added to the item below the duplicate_item call.
2. Another workaround is to use duplicate instead of duplicate_item and then apply your fix. duplicate does not have the limitation of needing the original code to be valid Rust code. Though, because it likely wouldn't be allowed in a trait definition, the whole impl likely needs to be wrapped in an empty duplicate/substitute.

I will still keep this issue open for the previously stated reason. Having duplicate fix this lint itself is off the table for now.

[threema-theo]

Hi,

Thank you for maintaining this extremely useful crate!

I ran into a similar problem with the multiple_inherent_impl lint. (Please tell me if a minimal example would help to understand the problem).

While the first workaround (turning lint off below duplicate_item call) works, we could also apply this programmatically to all generated items. This could be enabled with a feature flag (e.g., "allow_clippy_lints").

Would you be interested in a PR that introduces such a feature? Also, do you think it would integrate nicely with the current architecture?

[Emoun]

@threema-theo, thank you for also highlighting your issue.

However, you also just highlighted the point I made in my previous comment: If we start down this road, where does it end? We now have 2 clippy lints that must be accounted for and there likely are many more. Even if we now find them all and make duplicate add lint exceptions automatically, next year more lints will be added to clippy, and then we need to support them too. This is not sustainable for a crate that at this point is essentially finished and otherwise does not need much work to maintain.

I briefly considered whether your suggestion of a feature flag could work. We could even say that its support for clippy lints is on a "best effort" basis with no to few guarantees on future compatibility. But even then, this crate would likely go from needing work done once or twice a year to several times that, as people notice more lints to support. I don't feel this is worth the benefit.

My decision is therefore that no, I will not accept a PR that adds support for clippy lints in the forms we have discussed or other similar "fixes". Not even hidden behind a feature flag. I'm sorry if this is not the decision you prefer.