`allow`s are not propagated to auto-generated `impl`s

[wprzytula]

Problem statement

Built-in derive macros (e.g., Debug) behave differently than thiserror::Error wrt propagation of #[allow(...)] attributes.

Built-in macros

allow attributes are propagated to auto-generated impls.

thiserror::Error

allow attributes are not propagated to auto-generated impls.

Example

#[deprecated]
#[allow(deprecated, never_type_fallback_flowing_into_unsafe)]
#[derive(Debug, Error)]
#[error("B")]
pub struct B;

gets expanded into (formatted for readability):

#[deprecated]
#[allow(deprecated, never_type_fallback_flowing_into_unsafe)]
#[error("B")]
pub struct B;

#[automatically_derived]
#[allow(deprecated, never_type_fallback_flowing_into_unsafe)]
impl ::core::fmt::Debug for B {
    #[inline]
    fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
        ::core::fmt::Formatter::write_str(f, "B")
    }
}

#[allow(unused_qualifications)]
#[automatically_derived]
impl ::thiserror::__private::Error for B {}

#[allow(unused_qualifications)]
#[automatically_derived]
impl ::core::fmt::Display for B {
    #[allow(clippy::used_underscore_binding)]
    fn fmt(&self, __formatter: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
        #[allow(unused_variables, deprecated)]
        let Self {} = self;
        __formatter.write_str("B")
    }
}

Proposed solution

Do propagate allows to impls generated by thiserror::Error.

[dtolnay]

Were you motivated to report this issue from running into any particular rustc or clippy lint in thiserror-generated code? Or purely from observing a difference in expansion compared to Debug?

[wprzytula]

I experienced problems with deprecations. Namely, having #[allow(deprecated)] on items with thiserror::Error derived did not silence compiler warning about using deprecated items.

[dtolnay]

Okay. For that, I think #393 is not the right fix. Notice that #[derive(Debug)] #[deprecated] pub struct B; does not require the user of the Debug derive to also add their own #[allow(deprecated)].

[wprzytula]

Okay. For that, I think #393 is not the right fix. Notice that #[derive(Debug)] #[deprecated] pub struct B; does not require the user of the Debug derive to also add their own #[allow(deprecated)].

Good catch. Would it be a valid solution to also #[allow(deprecated)] to all auto-generated impls if the item has the #[deprecated] attribute?

[dtolnay]

Does derive(Debug) do that?

[wprzytula]

Does derive(Debug) do that?

I've tested, and the answer is no. Then I'm not sure I understand what you mean here:

Notice that #[derive(Debug)] #[deprecated] pub struct B; does not require the user of the Debug derive to also add their own #[allow(deprecated)].

In what way it does not require the user?

If you're saying that derive(Debug) on #[deprecated] items does not trigger the compiler warning, then it's true, and it's strange:

#[deprecated]
#[error("B")]
pub struct B;

#[automatically_derived]
impl ::core::fmt::Debug for B {
    #[inline]
    fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
        ::core::fmt::Formatter::write_str(f, "B")
    }
}

This compiles without warnings, even though the deprecated B is referred to in impl ::core::fmt::Debug for B, which does not have the #[allow(deprecated)] attribute.

I suspect it's some kind of a compiler's special treatment to built-in derive macros? If so, in thiserror::Error we still have to emulate this by adding #[allow(deprecated)].

[wprzytula]

The problem about deprecations is not yet fully solved. The following code still triggers the lint:

#[derive(Error, Debug)]
#[allow(deprecated)]
pub enum A {
    #[error(transparent)]
    B(#[from] B),
}

[wprzytula]

Thank you @dtolnay! 💯