regression: cant compare `str` with `&str`

[BoxyUwU]

• https://crater-reports.s3.amazonaws.com/beta-1.82-1/beta-2024-09-05/reg/moar_options-0.1.1/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.82-1/beta-2024-09-05/gh/Embers-of-the-Fire.rust-std-ext/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.82-1/beta-2024-09-05/reg/rs-std-ext-0.2.0/log.txt

[INFO] [stdout] error[E0277]: can't compare `str` with `&str`
[INFO] [stdout]   --> src/lib.rs:29:40
[INFO] [stdout]    |
[INFO] [stdout] 29 |         assert!(input.is_none_or(|x| x == &"test"));
[INFO] [stdout]    |                                        ^^ no implementation for `str == &str`
[INFO] [stdout]    |
[INFO] [stdout]    = help: the trait `PartialEq<&str>` is not implemented for `str`, which is required by `&str: PartialEq<&&str>`
[INFO] [stdout]    = note: required for `&str` to implement `PartialEq<&&str>

I think this was caused by stabilizing is_none_or?

note: if this breakage was accepted by the relevant team then this issue can be closed.

[steffahn]

Indeed, this is caused by stabilization of is_none_or.

• Stabilize is_none_or #129086

Both crates (moar_options, rs-std-ext) are crates that provide an extension trait for Option with a is_none_or method (1) (2), and in either case, that method works with &self and passes &T to the callback; unlike the stabilized Option::is_none_or which works with self and passes T to the callback.

// difference in signature, on `Option<T>`

// extension traits from broken crates
fn is_none_or(&self, f: impl FnOnce(&T) -> bool) -> bool

// standard library, stabilized
fn is_none_or(self, f: impl FnOnce(T) -> bool) -> bool

Stabilization of the inherent method Option::is_none_or makes the inherent method take precedence over the extension traits, causing the error in those crates.

The crates both still work on beta, just their tests fail, and most users of the crates will likely fail if they make use of is_none_or.

Since 1.81, users of the either crate that use is_none_or are already receiving the following warning.

warning: a method with this name may be added to the standard library in the future
 --> src/main.rs:5:14
  |
… |     …………………).is_none_or(|…| {
  |              ^^^^^^^^^^
  |
  = warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
  = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
  = help: call with fully qualified syntax `is_none_or(...)` to keep using the current method
  = note: `#[warn(unstable_name_collisions)]` on by default

However, since unstable is_none_or was not present in 1.80 or earlier yet, this means there’s only a single release cycle that displays this warning.

[m-ou-se]

@mztikk @Embers-of-the-Fire Heads up: the stablization of is_none_or in std will affect your crates. (The new is_none_or in std will pass the value by value rather than by reference.)

[m-ou-se]

Discussed in libs meeting; we consider this acceptable.