[ConstraintSystem] Further unwrap cleanup

[gregomni]

This was part of PR #18324

If shouldAttemptFixes() then when we are trying to bind type variables, if T? fails, then attempt to bind T for all binding types. This was already happening and valid for subtype bindings. This change tries it for supertype and identity bindings because it allows us the opportunity to matchTypes() a T? value to a T bound variable by diagnosing a missing unwrap.

This was the only situation in which we were previously missing finding that Fix in the constraint system, so with this change all of the unwrap diagnosis can be moved into the new CSDiagnostics.cpp and made static.

[gregomni]

cc @xedin @rudkx

[gregomni]

@swift-ci Please smoke test

[gregomni]

@swift-ci Please smoke test

[gregomni]

Looks like checks failed because they hadn't included #18324 yet.

@swift-ci Please smoke test.

[xedin]

As I mentioned in previous PR, this make sense to me! Could you try recording a fix right away? It seems like that should work, and duplicate fix should be ignored (when attempted) later on because it would have the same locator?

[gregomni]

I investigated this further, and the issue is slightly different than I originally thought, and I don't think there's any good way to construct the needed fix(es) in advance. The test that addresses this is SR-1069 which is in tests/Constraints/closures.swift.

Even further simplified, the issue arises here:

class C {}
struct S {
  func genericallyNonOptional<T: AnyObject>(_ non: T) {}

  func f(object: C?) {
    genericallyNonOptional(object)
  }
}

T can't be bound to C? because Optional isn't a class type, so we want to bind T to C and emit a missing unwrap.

Interestingly, without this PR the current code handles the above fine, but breaks down with a mix of multiple arguments:

class C {}
struct S {
  func genericallyNonOptional<T: AnyObject>(_ a: T, _ b: T, _ c: T) { }

  func f(_ a: C?, _ b: C?, _ c: C) {
    genericallyNonOptional(a, b, c) // cannot invoke 'genericallyNonOptional' with an argument list of type '(C?, C?, C)' // expected an argument list of type '(T, T, T)'

  }
}

... whereas after this PR, we get the much better suggestion of unwrap fixits for arguments a and b. Will add a test to this effect.

[gregomni]

@swift-ci Please smoke test.

[xedin]

Sounds good to me!

[gregomni]

@swift-ci Please smoke test