`T: Unsize<?infer>` doesn't force the goal to be ambig, uses where-bounds

[lcnr]

#![feature(unsize)]
use std::marker::Unsize;
fn meta_offset_layout<T: Unsize<U>, U>(value: &T) -> U
{
    meta_offset_layout(value)
}

fails with

error[E0277]: the trait bound `U: Unsize<U>` is not satisfied
 --> src/main.rs:5:24
  |
5 |     meta_offset_layout(value)
  |     ------------------ ^^^^^ the nightly-only, unstable trait `Unsize<U>` is not implemented for `U`
  |     |
  |     required by a bound introduced by this call
  |
  = note: all implementations of `Unsize` are provided automatically by the compiler, see <https://doc.rust-lang.org/stable/std/marker/trait.Unsize.html> for more information
note: required by a bound in `meta_offset_layout`
 --> src/main.rs:3:26
  |
3 | fn meta_offset_layout<T: Unsize<U>, U>(value: &T) -> U
  |                          ^^^^^^^^^ required by this bound in `meta_offset_layout`
help: consider restricting type parameter `U` with unstable trait `Unsize`
  |
3 | fn meta_offset_layout<T: Unsize<U>, U: std::marker::Unsize<U>>(value: &T) -> U
  |                                      ++++++++++++++++++++++++

in the new solver.

THis happens as coerce_unsize considers T: Unsize<?recursive_t>. While we bail with ambiguity in fn consider_structural_builtin_unsize_candidates, we assemble the ParamEnv candidate regardless and prefer that over the impl, constraining ?recursive_t to the U due to the where-clause.

See https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/.60static-box.60.20unsize.20issue/with/569043447. We could weaken candidate preference in the new solver to avoid this behavior, but I don't think that's necessarily worth the complexity.

This can only be triggered using unstable code, as it needs explicit Unsize where-clauses. It breaks static-box

[lcnr]

we could fix this by:

• change the trait solver itself to weaken candidate preference. this feels desirable in general, but feels iffy if we only do it for Unsize
• change the CoerceVisitor to check Unsize goals for infer vars in the target type, and if so, bail. That seems easy enough 🤷

[adwinwhite]

change the CoerceVisitor to check Unsize goals for infer vars in the target type, and if so, bail. That seems easy enough

It seems that we have no way of detecting these infer vars inside the visitor.
Goals in ProofTree have their infer vars unified since the root goal evaluation is already completed.

[lcnr]

True xx this is really annoying :/

so actually, this is not easy. Changing proof tree visitors to not constrain stuff when initially proving the goal seems kinda hard, but also very much desirable.

I don't quite know how to implement this. We could certainly simply not apply the query response after computing a proof tree to leave the infer vars in there unconstrained until we constrain them in the goal. Unsure 🤔 probably valuable to experiment with this.

In a sense https://github.com/rust-lang/rust/blob/78df2f92de1da3601d967dc8beb9f9cea267e45f/compiler/rustc_next_trait_solver/src/solve/eval_ctxt/mod.rs#L1525-L1531 should just not use the orig_values but just unconstrained infer vars 🤔 alternatively add a version of instantiate_and_apply_query_response that never constrains the instantiated var_values of the goal but just returns em

[lcnr]

Given that this is difficult, moving it back to "potentially irrelevant" as I don't think this should cause us to delay stabilization