Use rustversion to detect available Rust version

`tinyvec` currently uses crate features `rustc_1_40`, `rustc_1_55`,
and `rustc_1_57` to enable functions and optimizations that require
Rust versions higher than the library's base MSRV of 1.34.0.

This patch replaces the uses of these crate features with dtolnay's
macro `rustversion`, which automatically detects the version of
`rustc` with which the code is being compiled, thus allowing the
optimizations enabled by newer Rust versions to be applied regardless
of whether a dependent requests any of the `rustc_*` crate features.
This may be especially useful for dependents whose own MSRVs would bar
them from using those crate features without gating them behind crate
features of their own, potentially requiring a proliferation of such
crate features through a dependency tree.

I would have limited this patch to using `rustversion` to enable
optimizations automatically and not to replace the use of the crate
features to gate functions that require Rust versions newer than
1.34.0, because I thought that using `rustversion` rather than the
crate features to gate such functions might have been undesirable
because it would mean losing the "Available on crate feature xyz only"
hints on Docs.rs, but I see that Docs.rs doesn't apply those hints to
functions anyway, so no such hints are lost by switching the gating
mechanism to `rustversion`.

This patch further uses `rustversion` to add compilation errors in
case one of the `rustc_*` crate features is requested and the
available Rust version is too old, such that the `rustc_*` crate
features now function simply as static assertions that the running
`rustc` supports the indicated Rust version.

This patch, of course, adds a dependency on `rustversion`, which
becomes this library's only non-optional dependency.  Its MSRV is
1.31.0 and so does not raise the MSRV of this library.  If having a
non-optional dependency is unacceptable, an alternative could be to
have `rustversion` be an optional, on-by-default dependency and to
rely on the `rustc_*` crate features as before if `rustversion` is
disabled.  Rather than

    #[rustversion::since(1.57)]

the conditional compilation clauses would look like

    #[cfg(any(feature = "rustversion", feature = "rustc_1_57"))]
    #[cfg_attr(feature = "rustversion", rustversion::since(1.57))]

which is verbose enough that I suspect that rejecting `rustversion`
altogether would be preferred.

I admit that I do not understand why the comment in `Cargo.toml` on
the crate feature `rustc_1_40` seems to say that "us[ing] Vec::append
if possible in TinyVec::append" and overriding
`DoubleEndedIterator::nth_back` require Rust 1.37 and Rust 1.40
respectively, when the standard library documentation says that
`Vec::append` and `DoubleEndedIterator::nth_back` were stabilized in
Rust 1.4.0 and Rust 1.37.0 respectively.

Author: 8573

Cargo.toml

@@ -15,6 +15,8 @@ tinyvec_macros = { version = "0.1", optional = true }
 serde = { version = "1.0", optional = true, default-features = false }
 # Provides derived `Arbitrary` implementations
 arbitrary = { version = "1", optional = true }
+# Detects the available `rustc` version
+rustversion = "1.0.7"
 
 [features]
 default = []
@@ -29,17 +31,20 @@ std = ["alloc"]
 # "active" portion of an `ArrayVec` or `SliceVec`.
 grab_spare_slice = []
 
-# features that require rustc 1.40
+# formerly enabled features that require rustc 1.40
 # use Vec::append if possible in TinyVec::append - 1.37
 # DoubleEndedIterator::nth_back - 1.40
+# now these are automatically enabled if the listed rustc versions are detected
 rustc_1_40 = []
 
-# features that require rustc 1.55
+# formerly enabled features that require rustc 1.55
 # use const generics to implement Array for all array lengths
+# now that is automatically enabled if rustc 1.55+ is detected
 rustc_1_55 = ["rustc_1_40"]
 
-# features that require rustc 1.57
+# formerly enabled features that require rustc 1.57
 # add try_reserve functions to types that heap allocate.
+# now that is automatically enabled if rustc 1.57+ is detected
 rustc_1_57 = ["rustc_1_55"]
 
 # allow use of nightly feature `slice_partition_dedup`,

gen-array-impls.sh

@@ -3,6 +3,7 @@
 gen_impl() {
 	local len=$1
 	cat <<-END
+		#[rustversion::before(1.55)]
 		impl<T: Default> Array for [T; $len] {
 		  type Item = T;
 		  const CAPACITY: usize = $len;
@@ -43,6 +44,7 @@ cat <<-END
 	//     ./gen-array-impls.sh > src/array/generated_impl.rs
 	// from the repo root
 
+	#[rustversion::before(1.55)]
 	use super::Array;
 
 	$(for ((i = 0; i <= 33; i++)); do gen_impl $i; done)

src/array.rs

@@ -8,9 +8,10 @@
 ///
 /// You are generally **not** expected to need to implement this yourself. It is
 /// already implemented for all the major array lengths (`0..=32` and the powers
-/// of 2 up to 4,096), or for all array lengths with the feature `rustc_1_55`.
+/// of 2 up to 4,096), or for all array lengths in Rust versions 1.55 and newer.
 ///
-/// **Additional lengths can easily be added upon request.**
+/// **Additional lengths can easily be added upon request for Rust 1.54 and
+/// older.**
 ///
 /// ## Safety Reminder
 ///
@@ -41,8 +42,12 @@ pub trait Array {
   fn default() -> Self;
 }
 
-#[cfg(feature = "rustc_1_55")]
+// These `*_impl` modules implement `Array` for primitive arrays.
+//
+// NOTE(2022-07-09): The `#[rustversion::...]` conditional compilation
+// attributes are placed on the individual implementation blocks rather than on
+// the modules because using procedural attribute macros on non-inline modules
+// is unstable.  Even if doing so becomes stable, it would be incompatible with
+// `tinyvec`'s MSRV.
 mod const_generic_impl;
-
-#[cfg(not(feature = "rustc_1_55"))]
 mod generated_impl;

src/array/const_generic_impl.rs

@@ -1,5 +1,7 @@
+#[rustversion::since(1.55)]
 use super::Array;
 
+#[rustversion::since(1.55)]
 impl<T: Default, const N: usize> Array for [T; N] {
   type Item = T;
   const CAPACITY: usize = N;