Rust 1.40.0 nightly breaks specialization

[althonos]

🐛 Bug Reports

When reporting a bug, please provide the following information. If this is not a bug report you can just discard this template.

🌍 Environment

• Your operating system and version: ArchLinux
• Your python version: Python 3.7
• How did you install python (e.g. apt or pyenv)? Did you use a virtualenv?: pacman, no.
• Your rust version (rustc --version): cargo 1.40.0-nightly (8b0561d68 2019-09-30)
• Are you using the latest pyo3 version: using master

💥 Reproducing

Building using the latest nightly Rust compiler gives 89 errors caused by functions being specialized without having been marked as default:

error[E0520]: `drop_impl` specializes an item from a parent `impl`, but that item is not marked `default`
   --> src/instance.rs:595:5
    |
580 | impl<T: ToPyObject + ?Sized> ManagedPyRefDispatch for T {}
    | ---------------------------------------------------------- parent `impl` is here
...
595 |     fn drop_impl(_: &mut ManagedPyRef<T>) {}
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot specialize default item `drop_impl`
    |
    = note: to specialize, `drop_impl` in the parent `impl` must be marked `default`

error: aborting due to 89 previous errors

[konstin]

This was introduced by rust-lang/rust#64564. Afaik this should fixable by adding default in a bunch of impls.

[kngwyu]

Wow 🤔
So this means that we still highly depend on specialization?
This fact makes me rethink our roadmap to stable...
Like #210, our attempt is around removing specialization, but ... isn't it better to wait for it stabilized?
Specialization is a nice feature. It's efficient in that we can select algorithms at compile-time and easy to implement.
The problem is, of course, it is still highly nightly, though.

[althonos]

@konstin : actually the default implementation needs to be moved out of the trait for the default fn to work, because for some reason default fn in trait implementation does not work.

I'm trying my luck with a PR.

[konstin]

So this means that we still highly depend on specialization?

Most of the ~90 instances of specialization are in the protocols, which always follow the same structure. That's why I made #552 to show that it's possible to have protocols without specialization.

Like #210, our attempt is around removing specialization, but ... isn't it better to wait for it stabilized?

Afaik there are still a lot unresolved questions and even some soundness holes (s. rust-lang/rust#31844), so I don't expect this to be stabilized any time soon.