Some doc and test cleanups mainly around specialization

README.md

@@ -4,7 +4,7 @@
 [![Actions Status](https://github.com/PyO3/pyo3/workflows/Test/badge.svg)](https://github.com/PyO3/pyo3/actions)
 [![codecov](https://codecov.io/gh/PyO3/pyo3/branch/master/graph/badge.svg)](https://codecov.io/gh/PyO3/pyo3)
 [![crates.io](http://meritbadge.herokuapp.com/pyo3)](https://crates.io/crates/pyo3)
-[![minimum rustc 1.42](https://img.shields.io/badge/rustc-1.39+-blue.svg)](https://rust-lang.github.io/rfcs/2495-min-rust-version.html)
+[![minimum rustc 1.39](https://img.shields.io/badge/rustc-1.39+-blue.svg)](https://rust-lang.github.io/rfcs/2495-min-rust-version.html)
 [![Join the dev chat](https://img.shields.io/gitter/room/nwjs/nw.js.svg)](https://gitter.im/PyO3/Lobby)
 
 [Rust](http://www.rust-lang.org/) bindings for [Python](https://www.python.org/). This includes running and interacting with Python code from a Rust binary, as well as writing native Python modules.

guide/src/class.md

@@ -888,12 +888,12 @@ documentation](https://docs.python.org/3/library/stdtypes.html#iterator-types).
 Users should be able to define a `#[pyclass]` with or without `#[pymethods]`, while PyO3 needs a
 trait with a function that returns all methods. Since it's impossible to make the code generation in
 pyclass dependent on whether there is an impl block, we'd need to implement the trait on
-`#[pyclass]` and override the implementation in `#[pymethods]`, which is to the best of my knowledge
-only possible with the specialization feature, which can't be used on stable.
-
-To escape this we use [inventory](https://github.com/dtolnay/inventory),
+`#[pyclass]` and override the implementation in `#[pymethods]`.
+To enable this, we use a static registry type provided by [inventory](https://github.com/dtolnay/inventory),
 which allows us to collect `impl`s from arbitrary source code by exploiting some binary trick.
 See [inventory: how it works](https://github.com/dtolnay/inventory#how-it-works) and `pyo3_derive_backend::py_class` for more details.
+Also for `#[pyproto]`, we use a similar, but more task-specific registry and
+initialize it by [ctor](https://github.com/mmastrac/rust-ctor) crate.
 
 Specifically, the following implementation is generated:
 

guide/src/rust_cpython.md

@@ -6,7 +6,7 @@ This chapter is based on the discussion in [PyO3/pyo3#55](https://github.com/PyO
 
 ## Macros
 
-While rust-cpython has a macro based dsl for declaring modules and classes, PyO3 uses proc macros and specialization. PyO3 also doesn't change your struct and functions so you can still use them as normal Rust functions.
+While rust-cpython has a macro based dsl for declaring modules and classes, PyO3 uses proc macros. PyO3 also doesn't change your struct and functions so you can still use them as normal Rust functions.
 
 **rust-cpython**
 

tests/test_compile_error.rs

@@ -13,8 +13,7 @@ fn test_compile_errors() {
         t.compile_fail("tests/ui/wrong_aspyref_lifetimes.rs");
         t.compile_fail("tests/ui/invalid_pymethod_names.rs");
     }
-
-    #[rustversion::all(since(1.43))]
+    #[rustversion::since(1.43)]
     fn testcase_latest_stable(t: &trybuild::TestCases) {
         t.compile_fail("tests/ui/static_ref.rs");
     }