Rollup merge of #60185 - NieDzejkob:int-error-kind-reexport, r=rkruppe

Reexport IntErrorKind in std

Currently `IntErrorKind` can only be found in `core`. @Centril confirmed on Discord that this is unintentional (should I r? him in this situation?).

Should there be a test for this? As far as this *specific* situation goes, I don't think so, I'll risk it and say that there's no way this regresses. However, it might be a good idea to have some tool detect public items in `core` that are not reexported in `std`. Does this belong in tidy, or should that be a separate tool? Is there some rustc-specific *linter*? Unless that's entirely a dumb idea, this should probably get an issue.

Note: My local build hasn't finished yet, but it's well past the point where I would expect problems.

src/libstd/lib.rs

@@ -267,6 +267,7 @@
 #![feature(hash_raw_entry)]
 #![feature(hashmap_internals)]
 #![feature(int_error_internals)]
+#![feature(int_error_matching)]
 #![feature(integer_atomics)]
 #![feature(lang_items)]
 #![feature(libc)]

src/libstd/num.rs

@@ -16,6 +16,12 @@ pub use core::num::{NonZeroU8, NonZeroU16, NonZeroU32, NonZeroU64, NonZeroU128,
 #[stable(feature = "signed_nonzero", since = "1.34.0")]
 pub use core::num::{NonZeroI8, NonZeroI16, NonZeroI32, NonZeroI64, NonZeroI128, NonZeroIsize};
 
+#[unstable(feature = "int_error_matching",
+           reason = "it can be useful to match errors when making error messages \
+                     for integer parsing",
+           issue = "22639")]
+pub use core::num::IntErrorKind;
+
 #[cfg(test)] use crate::fmt;
 #[cfg(test)] use crate::ops::{Add, Sub, Mul, Div, Rem};