1.97 beta regression due to name collision with `highest_one`

[theemathas]

Regression discovered in the 1.97 beta crater run.

[INFO] [stdout] error[E0605]: non-primitive cast: `Option<u32>` as `i8`
[INFO] [stdout]   --> src/main.rs:58:58
[INFO] [stdout]    |
[INFO] [stdout] 58 |                 #[inline] fn highest_one(self) -> Self { (self as $ux).highest_one() as _ }
[INFO] [stdout]    |                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ an `as` expression can be used to convert enum types to numeric types only if the enum type is unit-only or field-less
[INFO] [stdout] ...
[INFO] [stdout] 65 | impl_common_num_ext!(i8 = u8, i16 = u16, i32 = u32, i64 = u64, i128 = u128, isize = usize);
[INFO] [stdout]    | ------------------------------------------------------------------------------------------ in this macro invocation
[INFO] [stdout]    |
[INFO] [stdout]    = note: see https://doc.rust-lang.org/reference/items/enumerations.html#casting for more information
[INFO] [stdout]    = note: this error originates in the macro `impl_common_num_ext` (in Nightly builds, run with -Z macro-backtrace for more info)

(Repetitive errors omitted for brevity.)

https://crater-reports.s3.amazonaws.com/beta-1.97-3-v2/1.97.0-beta.1/gh/Spheniscine.heightmap-gen/log.txt

Presumably regressed in #155147. cc @sorairolake, @jhpratt

[jhpratt]

I thought trait methods that were in scope took precedence over inherent methods? On the assumption that the highest_one method that the crate has from before was an extension trait.

[theemathas]

@jhpratt It's the opposite. Inherent methods take precedence over trait methods.

[jhpratt]

Not really anything that can be done about this then? Presumably this would be considered acceptable breakage, assuming it's not too large in scale. I've not looked at the crater run, admittedly.