fallback to resolve infer generics in type-changing-struct-update

[SparrowLii]

Fixes#101970
When creating a struct with a base struct, we store the base struct's type which has infer generics. And then unify it with the created struct's generics through a function-body-scoped fallback during typeck.
cc #86555

[rust-highfive]

r? @estebank

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

[SparrowLii]

cc @compiler-errors@nikomatsakis

[bors]

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

[compiler-errors]

Why are you throwing this result away?

[SparrowLii]

The purpose of this code is to instantiate the uninstantiated infer generic created for base_expr in check_expr_struct_fields by calling the relate_generic_arg function. If Err is returned, the generic type has been instantiated by the type of base_expr itself and is not constrained by the created struct (constrained ones hav been checked in check_expr_struct_fields).

[SparrowLii]

Perhaps we can have a more accurate approach, such as maintaining a non-constrained generic indexes list for base_expr.

[estebank]

Given that this is purely for diagnostics, this approach might be fine, but including what you wrote above as a comment would be welcome.

[compiler-errors]

Given that this is purely for diagnostics

I'm confused by this comment. This isn't purely diagnostic, I thought? My understanding is that this function affects type inference -- notably, relate_generic_arg is also not an atomic operation, so even if it returns Err, it can still partially constrain inference variables inside of that.

I'm not convinced that this approach is completely sound. I would be comfortable with something more along the lines of:

such as maintaining a non-constrained generic indexes list for base_expr.

At least in that case it's easier to reason about when we're allowed to unify unconstrained inference variables and when we expect to raise errors.

[bors]

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

[fee1-dead]

Can we do a crater run to see if this will fix all breakages? On the issue the lang team expressed that this could be done via an edition change, but wouldn't it just work as good if this would resolve them? cc @scottmcm

[estebank]

@bors try

@craterbot run

[craterbot]

🚨 Error: missing start toolchain

🆘 If you have any trouble with Crater please ping @rust-lang/infra!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout type-changing-struct-update(switch to your branch)
2. git fetch upstream master(retrieve the latest master)
3. git rebase upstream/master -p(rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self type-changing-struct-update --force-with-lease(update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging compiler/rustc_middle/src/ty/relate.rs
Auto-merging compiler/rustc_middle/src/ty/error.rs
Auto-merging compiler/rustc_middle/src/ty/context.rs
Auto-merging compiler/rustc_infer/src/infer/mod.rs
Auto-merging compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs
Auto-merging compiler/rustc_hir_typeck/src/expr.rs
CONFLICT (content): Merge conflict in compiler/rustc_hir_typeck/src/expr.rs
Auto-merging compiler/rustc_hir_typeck/src/demand.rs
CONFLICT (content): Merge conflict in compiler/rustc_hir_typeck/src/demand.rs
Auto-merging compiler/rustc_hir_analysis/src/check/mod.rs
CONFLICT (content): Merge conflict in compiler/rustc_hir_analysis/src/check/mod.rs
Automatic merge failed; fix conflicts and then commit the result.

[fee1-dead]

@rustbot author

[fee1-dead]

@bors try

[bors]

⌛ Trying commit 61fd9d5 with merge cbe8532756bbbc4b7f32dda40d05981c8aeffd80...

[SparrowLii]

Just rebased the PR. We can have a crate run first

[bors]

☀️ Try build successful - checks-actions
Build commit: cbe8532756bbbc4b7f32dda40d05981c8aeffd80 (cbe8532756bbbc4b7f32dda40d05981c8aeffd80)

[fee1-dead]

@craterbot run

[craterbot]

👌 Experiment pr-102129 created and queued.
🤖 Automatically detected try build cbe8532756bbbc4b7f32dda40d05981c8aeffd80
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[fee1-dead]

@craterbot abort

[craterbot]

🗑️ Experiment pr-102129 deleted!

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[fee1-dead]

@craterbot check

[craterbot]

👌 Experiment pr-102129 created and queued.
🤖 Automatically detected try build cbe8532756bbbc4b7f32dda40d05981c8aeffd80
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-102129 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-102129 is completed!
📊 82 regressed and 14 fixed (247865 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[estebank]

I'm going to reroll, I don't have the bandwidth for this PR at the moment.

r? compiler

[compiler-errors]

r? @compiler-errors

This still seems to leave some regressions according to the crater run. This definitely needs further discussion discussion on the changes to inference here, and I still have some concerns (#102129 (comment)) on the exact implementation that we're doing here.

[JohnCSimon]

@SparrowLii
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you are going to continue please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive