use_self lint fires on code expanded from a macro

[Lokathor]

When using a macro that expands to a particular fixed type, if you happen to use that macro in a context where Self could have been used the use_self lint will trigger and tell you to fix the macro.

Any way to make it not trigger on macro expansions?

[basil-cow]

I believe it was an explicit change introduced here, it used to not trigger on macro expansions, after the change it only triggers in local macro expansions.

[flip1995]

@Areredify is right: Issue: #2098, PR: #3627

You can fix a macro like this:

macro_rules! mac {
    ($ty:ident) => {{
        impl $ty {
            fn new() -> $ty {
                $ty { /* Some fields */ };
            }
        }
    }}
};

with:

macro_rules! mac {
    ($ty:ident) => {{
        impl $ty {
            fn new() -> Self {
                Self { /* Some fields */ };
            }
        }
    }}
};

If you found a case, where this is not possible, feel free to report it here and I'll reopen this issue.

[Lokathor]

I... absolutely don't follow your example code there. Those are very different. One is a trait impl and the other is an associated function impl.

Either way, my macro is this one here: https://github.com/Lokathor/wide/blob/master/src/m_f32x4.rs#L67 (as well as another similar one for i32x4, but let's focus on just one since a fix to this would fix the other)

And usages... all over the place in the module.

• Some are in contexts where Self would correctly give f32x4.
• Some are in contexts where Self would not give f32x4.
• In fact to be generally useful the macro must be valid in module scope where there's no Self at all.

[flip1995]

Oh, I simplified my example from a Trait impl to a simple impl, but forgot to edit a line. edited it now, sorry for the confusion.

Now I see your points. The easiest thing to do here would be just to disable it in macros again.

If we could distinguish if the self type came from $ty or just ty (was expanded or hard coded) we could disable the lint for types where the type is hard coded. We then had to address this

In fact to be generally useful the macro must be valid in module scope where there's no Self at all.

in some way. Maybe only lint in macros when we're inside an impl/trait definition.

[ArekPiekarz]

I've stumbled upon this bug when trying to pass the type name of Self into panic!:

use std::any::type_name;

trait ToI32 {
    fn to_i32(&self) -> i32;
}

impl ToI32 for f64 {
    fn to_i32(&self) -> i32 {
        if !self.is_finite() {
            panic!("Cannot convert {}: {} into i32", type_name::<Self>(), self);
        }
        *self as i32
    }
}

fn main() {
}

which emitted a warning:

warning: unnecessary structure name repetition
  --> src/main.rs:10:13
   |
10 |             panic!("Cannot convert {}: {} into i32", type_name::<Self>(), self);
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |