Elaborate destruct host effect clauses with structurally implied clauses

[ShoyuVanilla]

Fixes #144207

[rustbot]

r? @SparrowLii

rustbot has assigned @SparrowLii.
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

[compiler-errors]

I'm confused how a bound on clone_from can mean we remove a bound from clone. That seems backwards, since this function doesn't call clone_from?

[ShoyuVanilla]

I guess this might be okay since this bound was on impl, not fn clone?

[compiler-errors]

cc @rust-lang/project-const-traits this behavior definitely needs to be noted somewhere, and I'm not totally sure if it makes sense to imply by default, because it may have some unnecessary semver observable implications.

[compiler-errors]

If we did apply this, I'd probably want to abstract out the function that maps from a ty to its constituent types and share it between the Destruct trait logic and here. (T,): Destruct should probably imply T: Destruct, for example.

And [Ty; N]: Destruct should probably imply Ty: Destruct (perhaps except for 0, but that's another problem with the destruct trait...).

Logic would probably need to be pulled out of https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_next_trait_solver/solve/assembly/structural_traits.rs.html#743-820

[ShoyuVanilla]

Oh, absolutely I should do so and fill up missing cases for arrays and tuples. Thanks!

And it seems that I should also check for whether ManuallyDrop<T>: Destruct bound accidentally implies the bound T: Destruct as well 😅

[ShoyuVanilla]

it may have some unnecessary semver observable implications.

I've thought more about this, and I believe there might be semver-breaking implications. For example:

// crate A
pub struct Foo<T> {
    inner: Bar<T>,
    // ...
}

// crate B, depends on crate A
const fn foobar<T>(foo: Foo<T>, bar: Bar<T>)
where
    Foo<T>: [const] Destruct,
{
    // Some code relying on the implied bound: `Bar<T>: [const] Destruct`
}

If crate A removes the private field inner: Bar<T> from Foo<T>, then foobar in crate B might break due to the loss of the implicitly inferred bound.

And I think the inverse can also happen with the current nightly rustc. For instance:

If crate A deletes private field inner: Bar<T> from Foo<T>, const fn foobar in crate B might suffer from the removal of implicit bound.

And I think the opposite direction might be happen in current nightly rustc, like:

pub struct Foo {
    // All fields currently satisfy `const Destruct`
    // ...
}

If a private field that does not implement const Destruct is added to Foo, it may invalidate the previously inferred Foo: const Destruct bound.

This suggests we might need to restrict structural Destruct inference to public fields only, to avoid semver breakage from purely private structural changes. 🤔

[fee1-dead]

I think we'd probably want to resolve this at the most restricted scope, i.e. when comparing impl'd method bounds with trait method bounds.

I'm imagining us doing some sort of special elaboration for T: ~const Destruct bounds to pierce destruct bounds (Option<T>: ~const Destruct) into public fields. Since Option has all public fields we'd replace it with T: ~const Destruct. If a struct has both public and private fields e.g. struct Foo<T1, T2> { pub f1: T1, f2: T2, } we elaborate it to both Foo<T1, T2>: ~const Destruct and T1: ~const Destruct

This elaboration should also be gated behind a separate feature as it will probably have to stabilize separately to const traits

[ShoyuVanilla]

I think we'd probably want to resolve this at the most restricted scope, i.e. when comparing impl'd method bounds with trait method bounds.

I'm imagining us doing some sort of special elaboration for T: ~const Destruct bounds to pierce destruct bounds (Option<T>: ~const Destruct) into public fields. Since Option has all public fields we'd replace it with T: ~const Destruct. If a struct has both public and private fields e.g. struct Foo<T1, T2> { pub f1: T1, f2: T2, } we elaborate it to both Foo<T1, T2>: ~const Destruct and T1: ~const Destruct

This elaboration should also be gated behind a separate feature as it will probably have to stabilize separately to const traits

That sounds like the right approach to address the semver issue. Thanks! I’ll give it a try.

By the way, could I also ask your thoughts on the opposite direction? Specifically: what happens if we add a new private field to an ADT that does not implement const Destruct? Would that retroactively break any inferred const Destruct bounds?

(Sorry in advance if this is already designed/answered somewhere or just a misguided question 😅 )
Edit) Oh, I guess you meant both directions with the phrase "pierce destruct bounds into public fields" 😅 Nevermind.