Inference failure with `type_changing_struct_update`

[crlf0710]

In the crater run #98456, fajita crate regression exhibited inference failure. Here's a minimal repro:
// when feature gate is enabled below, the compilation fails.

#![feature(type_changing_struct_update)]

#[derive(Default)]
pub struct Foo<P, T> {
    pub t: T,
    pub v: P
}

impl<P: Default, T:Default> Foo<P, T> {
    pub fn o(t: T) -> Self {
        Foo { t, ..Default::default() }
    }
}

[crlf0710]

Just creating an issue for easier tracking.

cc #86555

[nikomatsakis]

We certainly knew this was a possibility when authoring the RFC -- based on the Zulip conversation, I believe that there were a number of inference failures of this kind, right?

The options on the table that I see are:

• Make the change anyway, breaking the crates.
• Make the change over an edition.
• Give up.

My sense was that there was a significant amount of breakage, making the first not an option. In that case, if we want to proceed, we should probably do the work to plan how we can make this an edition change (in particular, can we do migration?). I think we should be able to.

I'm going to nominate this issue to make the @rust-lang/lang team aware, but I'd appreciate it @crlf0710 if you or perhaps @compiler-errors could drop in more details about the scale of breakage found on crater.

[nikomatsakis]

@rustbot labels +I-lang-nomianted

[nikomatsakis]

@rustbot label +I-lang-nominated

[WaffleLapkin]

For some context, there is a zulip thread about finishing work on type-changing struct update.

And here is a MRE of this particular problem:

#![feature(type_changing_struct_update)]

#[derive(Default)]
struct Struct<T>(T);

fn _f() { Struct { 0: (), ..Default::default() }; }

If I understood correctly, @compiler-errors has an idea how we can hack inference to allow such examples. It's a hack though, so we may prefer to just do an editional breakage...

[compiler-errors]

For context, here's the experimentation I have done:

• without any additional inferences changes (1687 regressed): [NO MERGE] Enable type_changing_struct_update always (crater run) #98456 (comment)
• With some inference hacks (13 regressed): [NO MERGE] Enable type_changing_struct_update always (crater run) #98456 (comment)

But even with those inference hacks there are still cases where we get failures.

The inference hack is in a6e4db2 but it's very much a hack.

[SparrowLii]

I understood the cause of the problem to some extent and should be able to submit a PR soon to fix it

[SparrowLii]

@rustbot claim

[crlf0710]

Posted my thoughts in Zulip https://rust-lang.zulipchat.com/#narrow/stream/293397-project-type-changing-struct-update/topic/Work.20needed.20to.20finish.20out.20RFC/near/299733175