NLL doesn't check that user type annotations are well-formed in unreachable code

[matthewjasper]

#54942 checks well-formedness in the general case, but unreachable code is deleted before NLL can check it.

For example, this test still compiles with NLL enabled.

[pnkfelix]

Discussed at NLL weekly meeting. We need to decide whether this actually is something we're going to fix or not. Thus tagging as I-needs-decision.

The test provided currently fails to compile under -Z borrowck=migrate and thus we believe this problem will be flagged under the 2018 edition.

That gives us plenty of time to decide how we want to handle this in the long term.

Nonetheless, putting on the Release milestone so that we do actually make the aforementioned decision about whether to fix this.

[nikomatsakis]

I was thinking more about this. I think perhaps the way to fix this is as follows:

• Modify the MIR to put "user-provided type annotations" into a separate IndexVec that is part of the Mir struct, so that they are not embedded into random statements that will be removed by dead-code. Modify the statements and things to just keep an index into that vec. They should perhaps have a span though associated with them.
• Modify the NLL type-check to:
  • on entry, instantiate each of the user-given type annotations once with fresh type variables
  • also add Wf obligations for each of the resulting types (this subsumes the existing code that adds such obligations) with location Locations:All
  • for the statements that assert types, we just index into the "instantiated" vector to pull out the relevant type

[gnzlbg]

See also #55344 .

[pnkfelix]

triage: Either this is something that we're planning to implement and backport to the beta channel... or its something that is not that high priority.

Given that this is an NLL-sound issue, I'm going to assume that it is indeed high priority and belongs on the Release milestone.

Thus, tagging as P-high

[pnkfelix]

discussed at NLL meeting. @matthewjasper pointed out to me that this bug does not apply to migration mode, only to #![feature(nll)].

So, I am removing this from the Release milestone.

[pnkfelix]

Oh; looking over this now, I realize that the whole reason this was on the Release milestone was to resolve the I-needs-decision in a timely fashion. (And I was the one who even documented this, 21 days ago. 🤥 )

Putting back on the Release milestone.

[pnkfelix]

assigning to self for investigation of the issues that should drive the decision here (and perhaps the actual implementation).

[nikomatsakis]

I'm going to remove this from the release milestone. The current behavior is not even necessarily a bug, and it's definitely obscure and not something I expect a lot of people to run into. Moreover, the changes to fix those look fairly invasive, and I'm not eager to backport them -- I could easily imagine surprise ICEs resulting from such changes.