freeze type vars after structure is extracted

[nikomatsakis]

I'm pretty sure that it is possible for the following things to happen today:

1. We infer a type with bounds X <: T <: top
2. We resolve T structurally based on X
3. T acquires an upper bound and perhaps migrates away

I don't have a specific bad example, but I think it could lead to inconsistencies, perhaps with impl dispatch, perhaps elsewhere. This issue is kind of a note to myself to come up with some examples and make some tests and be sure we're ok. I think what it amounts to is that whenever we do a type-dependent operation, we should go back and assert this type as the upper-bound, so that the type inferencer doesn't come away with a more liberal upper-bound.

Our quite limited subtyping might also make this less relevant.

[graydon]

nominating this to move up to the "well defined" milestone. I don't entirely understand it but it sounds like a question of clear specification at very least.

[graydon]

sub-bug of #6834

[graydon]

accepted for well-defined milestone

[metajack]

visiting for triage. nothing to add.

[flaper87]

visiting for triage, it still seems relevant.

[nikomatsakis]

This is no longer relevant, given the new inference strategy wherein we instantiate type variables once and exactly one.