[Sema] Remove unneeded uses of TVO_CanBindToInOut

[davezarzycki]

In #15574, @CodaFi pointed out that @slavapestov added TVO_CanBindToInOut to the callers of createTypeVariable out of an "abundance of caution". This pull request removes TVO_CanBindToInOut as much as possible, without breaking the validation test suite. If this pull request is broken, then we probably need more tests to be added to the test suite.

[davezarzycki]

@swift-ci please test

[xedin]

@swift-ci please test source compatibility

[rudkx]

My only concern here is whether diagnostics regress as a result of our now failing to produce a solution for a constraint system as opposed to producing a solution and then emitting a diagnostic after.

I suspect we do not have good test coverage for those cases. Can you take a look at that, and add some tests that exercise diagnosing & in invalid positions where before your change we would have produced a solution?

[xedin]

I think that is potentially fixable by Fixes (that's probably the only viable way to go).

[xedin]

I also think it would be very helpful for future us if this was documented somehow...

[davezarzycki]

Hi @rudkx – I'm not clairvoyant, so if you know of new tests that need to be written, can you please elaborate? Thanks.

[CodaFi]

The tests here are particularly sensitive to changes in inout bindings. I'm pleasantly surprised they weren't tripped by these changes.

[davezarzycki]

Hi @CodaFi – Well… That's what happens when one runs ninja swift-check-validation for each use of TVO_CanBindToInOut or lack thereof. :-)

[davezarzycki]

How does one reproduce source compatibility failures? Specifically: ReactiveCocoa

[xedin]

@davezarzycki Looks like it's only ReactiveCocoa and it was caused by redeclaration fixes so consider it green for this case.

[davezarzycki]

Super. Out of respect to the tentative "make reviewing mandatory" policy discussion, can somebody please bless this pull request with approval? Thanks!

[xedin]

I think it looks great! We are still trying to figure out what to do about diagnostics here. Let's why for @rudkx to bless it.

[rudkx]

I didn't have a specific test case in mind. Just a general concern that when I attempted to remove the flag in getTypeForPattern we produced worse diagnostics. Perhaps we're not going to hit that in these other cases because they involve a RHS with & somewhere, which will produce an InOutExpr with the flag set on the type variable.

[slavapestov]

@davezarzycki @rudkx I'm in favor of this change. If any diagnostics are discovered to have regressed later, we should fix how we diagnose inout. @xedin was looking at that. It's broken right now anyway.