Add some AsRef implementations for smart pointers

[MatthijsKok]

Implements part of #132138

This is my first time contributing to the Rust Project.
Please let me know if I need to make any changes, or update the PR in any way.
I have read the contributing guidelines.

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jhpratt]

as something that needs FCP,

r? libs

[xizheyin]

CI failed. You can check for success locally before pushing. :)

[MatthijsKok]

CI failed. You can check for success locally before pushing. :)

Thanks for the suggestion, thats very useful :) I think I fixed the CI now, at least it works locally. CI is green!

[ibraheemdev]

r? libs-api

[thaliaarchi]

I think Arc should be done together with Rc, and probably UniqueRc too. I don’t think the reference counted types should grow apart.

[MatthijsKok]

I think Arc should be done together with Rc, and probably UniqueRc too. I don’t think the reference counted types should grow apart.

Yes that was my initial plan as well. However, adding the same impl blocks for Arc resulted in compilation errors inside src/tools/rust-analyzer's smol_str dependency, and I wanted to not add changes "all over the place" for my first PR.

I could try to resolve the errors produced by adding back Arc. If the diff that fixes it is relatively small, would you like me to add it back?

[thaliaarchi]

I think we're going to get inference failures with any amount of AsRef impls, unfortunately. My guess is the merit of this PR will be judged by the extent of the inference failures seen in a crater run, though I'm not a rust-lang reviewer.

I think this PR should either be only Box or Box, Rc, Arc, and UniqueRc. I suspect you're seeing inference failures for Arc<str> and not Rc<str>, because Arc<str> is more popular. Limiting it to Box would probably be wise, unless libs-api reviewers want to do a go/no-go with all of them.

[dtolnay]

Thanks for the PR!

I am not confident than any of these can be added without widespread breakage. For example, the new Box impls break pretty reasonable-looking code like the following:

fn main() {
    let b = "...".to_owned().into_boxed_str();
    println!("{}", b.as_ref());
}

error[E0283]: type annotations needed
 --> src/main.rs:3:22
  |
3 |     println!("{}", b.as_ref());
  |                      ^^^^^^
  |
  = note: multiple `impl`s satisfying `Box<str>: AsRef<_>` found in the following crates: `alloc`, `std`:
          - impl AsRef<OsStr> for Box<str>;
          - impl AsRef<Path> for Box<str>;
          - impl<A> AsRef<[u8]> for Box<str, A>
            where A: Allocator;
          - impl<T, A> AsRef<T> for Box<T, A>
            where A: Allocator, T: ?Sized;
help: try using a fully qualified path to specify the expected types
  |
3 -     println!("{}", b.as_ref());
3 +     println!("{}", <Box<str> as AsRef<T>>::as_ref(&b));
  |

If you'd like to see a crater run, I would recommend starting with just 1 single new impl, whichever of these is your favorite. Please send a separate PR for each impl that we should crater, and we can keep this PR as-is to keep track of all the impls we'd ideally like to add.