Include adjustments to allow unsizing coercions for raw slice pointers in receiver position

[b-naber]

Tries to fix #74679

This change would allow calling methods defined for raw slice pointers directly on raw array pointers. The current implementation might have some problems, the idea is to insert adjustments for raw pointers in receiver position if the receiver type is a raw array pointer and a method candidate has a raw slice pointer as its self_ty. This could possibly be problematic, since we implicitly deref a raw pointer. However, currently the only methods that allow this type of unsizing coercion are unsafe, but we might need to only allow these types of coercions for unsafe methods in general.

cc @RalfJung

[rust-highfive]

r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

[oli-obk]

I am surprised we need this much work inside the compiler. I thought unsizing had impls in libcore. I can try to review this, but I have little knowledge about the coercion part of typeck. It just feels suprising to me to have special cases added on top of the existing infrastructure.

cc @rust-lang/lang This adds a new unsizing coercion for raw pointers

[b-naber]

The title was probably poorly chosen. What we do here is not actually the unsizing itself, but rather we just adjust the self_ty in a way that allows method candidate search to find the right method. The correct method candidate is generated for a self_ty of type [_], because the compiler previously didn't allow deref adjustments for raw pointers, we had to include this (in autoderef_self_ty). But then we also have to auto autoref this deref'd self_ty again, but the compiler previously only did this for references not raw pointers. We limit these raw pointer to adjustments to the case when we're dealing with raw array pointers and the generated candidate is a slice.

[oli-obk]

Ah, that does make more sense, thanks!

The artificial limitation to array->slice unsizings could go away entirely if we wanted to, right? There's no inherent limitation since any unsizing operation doesn't actually look at the pointer to the concrete type.

I can review the implementation, but this needs sign-off from the lang team

[b-naber]

The artificial limitation to array->slice unsizings could go away entirely if we wanted to, right? There's no inherent limitation since any unsizing operation doesn't actually look at the pointer to the concrete type.

Ok cool, I didn't know that the unsizing operation doesn't look at the pointer. This would alleviate the safety concerns with the implementation and we could implement this in general and not just for array->slice unsizings.

[b-naber]

@oli-obk I'm not sure I understand what kind of unsize operations you expect this to work for. Currently in method resolution when the compiler generates autoderef steps it uses an unsafe flag only if the final_ty is an Array (this is done here in method_autoderef_steps). But the compiler e.g. doesn't use adjustments that take into account CoerceUnsized implementations. Can you explain in what other situations you would expect this to work besides array -> slice unsizings?

[oli-obk]

I think I am confusing this situation with a very similar one. The example I was thinking of is

#![feature(raw_ref_op)]

trait Foo {
}

impl Foo for i32 {
}

trait Bar: Sized {
    fn bar(self) {}
}

impl Bar for *const dyn Foo {
    fn bar(self) {}
}

fn main() {
    let x = 42_i32;
    let y = &raw const x;
    y.bar();
    let z: *const dyn Foo = y;
    z.bar();
}

but I do see that it is not exactly the same as the situation for slices here, since that is for inherent impls on raw pointers to slices instead of trait impls.

[RalfJung]

any unsizing operation doesn't actually look at the pointer to the concrete type

That's true right now but might stop being true with user-defined DST.

[crlf0710]

Triage: Added needs-fcp label since this needs sign-off from the lang team.

[bors]

☔ The latest upstream changes (presumably #82436) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

r? @nikomatsakis

[Mark-Simulacrum]

Waiting on Niko before lang team discussion.

[nikomatsakis]

Hi @b-naber, @RalfJung et al.--

Sorry for being slow on this PR. I have some questions! If I understand correctly, this PR is modifying method dispatch to add a kind of special case. I guess the first question is, why doesn't the unsizing impl apply? I guess because it would have to deref a raw pointer?

[crlf0710]

@b-naber Ping from triage, could you answer the question above here, or create a topic on zulip to discuss this further? thanks!

[crlf0710]

@b-naber Ping from triage, any updates on this?

[crlf0710]

@b-naber Ping from triage, any updates on this?

[crlf0710]

@b-naber Triage: I'm gonna close this due to inactivity. Feel free to reopen or create a new pr when you've got time to work on this again. Thanks!