Cannot derive(Debug) for a struct with a function with a reference parameter

[mathstuf]

This fails to compile:

#[derive(Debug)]
pub struct A {
    f: fn(&i64),
}

   Compiling no-debug v0.1.0 (file:///home/boeckb/misc/code/sb/rs-no-debug)                                                                                                                                                                                                                                                   
error[E0277]: the trait bound `fn(&i64): std::fmt::Debug` is not satisfied                                                                                                                                                                                                                                                    
 --> src/lib.rs:3:5
  |
3 |     f: fn(&i64),
  |     ^^^^^^^^^^^ `fn(&i64)` cannot be formatted using `:?`; if it is defined in your crate, add `#[derive(Debug)]` or manually implement it
  |
  = help: the trait `std::fmt::Debug` is not implemented for `fn(&i64)`
  = note: required because of the requirements on the impl of `std::fmt::Debug` for `&fn(&i64)`
  = note: required for the cast to the object type `std::fmt::Debug`

error: aborting due to previous error

It does work if the parameter is a non-reference (mutable reference also fails) including pointers. I'm using rustc 1.20.0 from Fedora's packages.

[anirudhb]

@mathstuf I think it has something to do with libcore/ptr.rs:

fnptr_impls_args! { }
fnptr_impls_args! { A }
fnptr_impls_args! { A, B }
fnptr_impls_args! { A, B, C }
fnptr_impls_args! { A, B, C, D }
fnptr_impls_args! { A, B, C, D, E }
fnptr_impls_args! { A, B, C, D, E, F }
fnptr_impls_args! { A, B, C, D, E, F, G }
fnptr_impls_args! { A, B, C, D, E, F, G, H }
fnptr_impls_args! { A, B, C, D, E, F, G, H, I }
fnptr_impls_args! { A, B, C, D, E, F, G, H, I, J }
fnptr_impls_args! { A, B, C, D, E, F, G, H, I, J, K }
fnptr_impls_args! { A, B, C, D, E, F, G, H, I, J, K, L }

What if we did this exact thing but with &A, &B, &C, etc.? I believe that should work.
I also encountered this same problem.

edit: also with &mut A, &mut B, &mut C, etc

[anirudhb]

Also, you can derive(Clone) for these types of structs, so you can just use a box.
I've tested this with fn(Box<u64>) -> u64, and it works fine. Link: Boxed functions

edit: better playground

[mathstuf]

@anirudhb If I need to store a function which takes a reference, how does a box solve any of that?

[anirudhb]

I was suggesting an alternative to storing functions that take references.

[anirudhb]

A box doesn't solve any of the problems you raised, but maybe a change to libcore/ptr.rs might work.

[mathstuf]

That works if you can change the interface, but that isn't always possible (e.g., storing something like u64::add_one).

[anirudhb]

No, I mean that fnptr_impl_args! was only called for A, B and such. Since it is a macro, passing in &A, &mut B etc. should work.

[mathstuf]

Heh, I think there was a race here :) . I was replying to "suggesting an alternative", not "but maybe a change to".

[mathstuf]

Also, doesn't the macro expansions become:

fnptr_impls_args! { }
fnptr_impls_args! { A }
fnptr_impls_args! { &A }
fnptr_impls_args! { &mut A }
fnptr_impls_args! { A, B }
fnptr_impls_args! { A, &B }
fnptr_impls_args! { A, &mut B }
fnptr_impls_args! { &A, B }
fnptr_impls_args! { &A, &B }
fnptr_impls_args! { &A, &mut B }
fnptr_impls_args! { &mut A, B }
fnptr_impls_args! { &mut A, &B }
fnptr_impls_args! { &mut A, &mut B }

Would raw pointer versions be needed as well? This seems…unwieldy.

[anirudhb]

Create another macro.

macro_rules! fnptr_impsl_argsptr {
   ($($arg: ident),+) => {
     fnptr_impls_args! { $($arg),+ };
     fnptr_impls_args! { $(&$arg),+ };
     fnptr_impls_args! { $(&mut $arg),+ };
   };
   () => {
     fnptr_impls_args! {};
   };
}

fnptr_impls_argsptr! { }
fnptr_impls_argsptr! { A }
fnptr_impls_argsptr! { A, B }
fnptr_impls_argsptr! { A, B, C }
fnptr_impls_argsptr! { A, B, C, D }
fnptr_impls_argsptr! { A, B, C, D, E }
fnptr_impls_argsptr! { A, B, C, D, E, F }
fnptr_impls_argsptr! { A, B, C, D, E, F, G }
fnptr_impls_argsptr! { A, B, C, D, E, F, G, H }
fnptr_impls_argsptr! { A, B, C, D, E, F, G, H, I }
fnptr_impls_argsptr! { A, B, C, D, E, F, G, H, I, J }
fnptr_impls_argsptr! { A, B, C, D, E, F, G, H, I, J, K }
fnptr_impls_argsptr! { A, B, C, D, E, F, G, H, I, J, K, L }

[anirudhb]

Macros solve repetition :)
edit: how would we enumerate all of the possibilities? we should probably start looking into compiler plugins.

[mathstuf]

No, that only does A, B, &A, &B, and &mut A, &mut B; A, &B is not generated with that (it's exponential in the number of variants of a type, your macro is still linear).

[anirudhb]

That's what my edit is for. We should look into a compiler plugin to do the enumeration.

[mathstuf]

Sorry, github doesn't autoload edits here, so I didn't see it.

[anirudhb]

I'm trying to think of a good way to enumerate A, &A, &mut A. Any ideas? @mathstuf

[anirudhb]

That is, for a certain length of list.

[Phlosioneer]

Fun fact: that's just a base-3 number with a number of digits equal to the number of parameters. Suuuuper easy to enumerate. For n params, that's 3^n macro invocations.

To be clear: 0 is A, 1 is &A, 2 is &mut A. Start with a 0 for each parameter. Then treat it as a number in base 3, and increment until you get back to all 0's. Every time you increment, do a fnptr_impls_argsptr! call.

I have no idea how to make a compiler plugin, or else I'd try doing this myself.

[RalfJung]

This doesn't just affect reference types though, it affects all types with lifetimes. The issue is that fn(&T) is short for for<'a> fn(&'a T), and the instances in libcore do not cover the case where there is a lifetime quantifier.

So, for example, once you covered fn(&T) and fn(&mut T), you still did not cover
fn( (&T, &mut T) ).

[mathstuf]

Blah. That increases the complexity considerably. I wonder if there shouldn't just be some compiler magic for fn X to just output the function's address?

[jethrogb]

Triage: This now works as expected on beta, but I don't know why.

[mathstuf]

Thanks for the update. Seems like #55517 from discussion on the referencing issue.

[jdahlstrom]

A bit late to the party now, but I'm not sure it would have been reasonable to generate over 3^12=531441 trait impls, compiler plugin or not...

[mathstuf]

Triage: This now works as expected on beta, but I don't know why.

Doesn't seem to work on stable today.

[Dylan-DPC]

This now works on latest stable and nightly so closing it