`#[implement]` yields `clippy::ptr_as_ptr` and `clippy::borrow_as_ptr`

[PaulDance]

Suggestion

Under windows 0.61.3 and Rust 1.86, using the implement macro on a type generates these two Clippy lints. Excluding them is bothersome, because it requires doing so on the entire module that contains interface implementations that most probably contain cases the lints are made for covering, thus loosing them entirely.

Would it therefore be possible to whitelist these lints in the generated code, but only for the precise locations they are triggered at? In doing so, it would be nice if expect were to be used, although it may conflict with the current MSRV. If that's not possible, then I would say prepending each allow with #[allow(clippy::allow_attributes)] should work in order to support warn-by-default configurations for this lint.

[kennykerr]

Please share a minimal repro.

[PaulDance]

Sure:

# `Cargo.toml`
[package]
name = "tmp"
version = "0.1.0"
edition = "2024"

[dependencies]
windows = { version = "0.61.3", features = [
    "std",
    "Win32",
    "Win32_System",
    "Win32_System_Com",
]}
windows-core = "0.61.2"

[lints]
clippy.borrow_as_ptr = "warn"
clippy.ptr_as_ptr = "warn"

and

// `src/lib.rs`
use std::ffi::c_void;
use windows::Win32::System::Com::{IClassFactory, IClassFactory_Impl};
use windows::core::{BOOL, GUID, IUnknown, Ref, Result, implement};

#[implement(IClassFactory)]
struct A;

impl IClassFactory_Impl for A_Impl {
    fn CreateInstance(
        &self,
        _outer: Ref<'_, IUnknown>,
        _iid: *const GUID,
        _object: *mut *mut c_void,
    ) -> Result<()> {
        Ok(())
    }

    fn LockServer(&self, _lock: BOOL) -> Result<()> {
        Ok(())
    }
}

then

$ cargo clippy --target x86_64-pc-windows-msvc
warning: `as` casting between raw pointers without changing their constness
 --> src/lib.rs:5:13
  |
5 | #[implement(IClassFactory)]
  |             ^^^^^^^^^^^^^ help: try `pointer::cast`, a safer alternative: `(IClassFactory as IClassFactory).cast::<IClassFactory>()`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_as_ptr
  = note: requested on the command line with `-W clippy::ptr-as-ptr`

warning: borrow as raw pointer
 --> src/lib.rs:5:13
  |
5 | #[implement(IClassFactory)]
  |             ^^^^^^^^^^^^^ help: try: `&raw const IClassFactory`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#borrow_as_ptr
  = note: requested on the command line with `-W clippy::borrow-as-ptr`

warning: `as` casting between raw pointers without changing their constness
 --> src/lib.rs:5:13
  |
5 | #[implement(IClassFactory)]
  |             ^^^^^^^^^^^^^ help: try `pointer::cast`, a safer alternative: `IClassFactory.cast::<IClassFactory>()`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_as_ptr

warning: `tmp` (lib) generated 3 warnings (run `cargo clippy --fix --lib -p tmp` to apply 3 suggestions)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.05s

under

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

[kennykerr]

Thanks for the repro! I took both lints for a spin on windows-rs but I'm not sure they are appropriate to support in general. Here are some observations:

• Neither are enabled by default and they appear to be classified as pedantic, meaning they are minor or subjective style issues that don't impact code correctness or performance.
• borrow_as_ptr in particular is highly subjective and actually suggests using addr_of_mut which is documented as "soft-deprecated" and unnecessary.
• ptr_as_ptr seems likes it could potentially be somewhat useful but its hard to experiment with because cargo clippy --fix fails so it looks like this lint is not well supported.
• I can see how the fact that the implement and interface macros may generate such warnings is bothersome but I don't really think its practical for the macros to comply to any or all potential pedantic warnings.

Happy for any feedback if you think otherwise.

[PaulDance]

I took both lints for a spin on windows-rs but I'm not sure they are appropriate to support in general.

Just to be clear, I'm not suggesting to add these lints to the windows-rs crates themselves, but for now only at least in the code generated by the macros.

Neither are enabled by default and they appear to be classified as pedantic, meaning they are minor or subjective style issues that don't impact code correctness or performance.

Yes, that is correct. However, they are still useful for readability, and help to avoid going too quickly in cases that require attention.

borrow_as_ptr in particular is highly subjective and actually suggests using addr_of_mut which is documented as "soft-deprecated" and unnecessary.

It enables complementing what the &raw (const|mut) notation intends to cover, and when used, it adequately doesn't trigger, so it's just the documentation lagging behind, really.

ptr_as_ptr seems likes it could potentially be somewhat useful but its hard to experiment with because cargo clippy --fix fails so it looks like this lint is not well supported.

It enables restricting types further, thus letting the compiler help as much as possible. Note that a lot, if not most (from my impression, I haven't checked exactly), of the lints are not MachineApplicable, so I wouldn't consider that to be an indication of the quality of their maintenance.

I can see how the fact that the implement and interface macros may generate such warnings is bothersome

It is indeed: one may not enable them exactly as wanted.

but I don't really think its practical for the macros to comply to any or all potential pedantic warnings.

I understand it could be viewed as a strong maintenance effort, but this is the first time it happens for us I think with window-rs, so it shouldn't be that much of a burden in the long run, I would say. Also, other projects doing code generation, like Serde or Prost, already do this in part, so it feels like it would be expected here as well. I imagine that setting up a test crate using the macros and running Clippy on the result in CI with pedantic lints would not be too hard and would help seeing this in advance.

At the very least, having already prepared a place in the macro implementations where the appropriate whitelisting attributes could be easily added by contributors whenever needed would be nice. I haven't checked this part of the code base yet, so maybe it already exists, in which case I would be happy to add these exclusions.

[ChrisDenton]

External macros shouldn't trigger most clippy lints. There may be a reason it does in this case but I think it more likely it's a bug in the lints. You could try opening a false positive issue on the clippy repo.

[PaulDance]

External macros shouldn't trigger most clippy lints.

Didn't know that, thanks.

You could try opening a false positive issue on the clippy repo.

Just did now! We'll see what comes of it.

[PaulDance]

As usual, I think this is prematurely closed, but whatever.

[Jarcho]

Stopping in from clippy. The reason this is linted is your use of quote_spanned! with the span of an input token. This hides the fact that these tokens came from a macro since the span contains the information about what macro things are from. What you really should set the span to is Span::call_site().located_at(other_token.span()) which will set the correct macro information and give you slightly better diagnostics when compiler errors happen with the generated code.

[PaulDance]

Thanks for the analysis @Jarcho.

@kennykerr would it therefore be possible to re-open this and attempt the suggested change?