[CSGen] Don't walk into ?? in LinkedExprAnalyzer.

[hborla]

Attempting to favor the type of this expression based on operand types is wrong, because this operator attempts to unwrap its operand types.

Resolves: rdar://85045881

[hborla]

@swift-ci please smoke test

[xedin]

@hamishknight I suspect this change is caused by the PR that removed function input constraint.

[xedin]

@hamishknight Since I referenced you, here is an explanation of what is going on here precisely. It's a regression cased by #39543, here - https://github.com/apple/swift/pull/39543/files#diff-5fffd7ce67aca13059738c34fbc714dcbaf3f6fe83daff7ca75836bc88304c20L1511-L1520. Constructor used to have a type variable for an argument type and now it doesn't, which means that type could flow up while generating constraints. That means that we could prefer wrong initializer if argument expression has a "common" result type. I think the PR I mentioned is correct, it's LinkedExprAnalyzer what is to blame here because it's too greedy once again...

[hamishknight]

I'm not sure this was caused by #39543, from what I can tell it appears to be fallout from #38836. Reverting the former didn't appear to fix the issue, but reverting the latter did.

It seems in computeFavoredTypeForExpr we can assign a favored type to a function argument, but we don't propagate it to any ParenExprs that wrap it. Therefore when walking with ConstraintOptimizer, we would previously not pick up that favored type in favorMatchingOverloadExprs, as for a unary unlabeled arg there'd be an intermediate ParenExpr. With the elimination of ParenExpr and TupleExpr argument lists however, there's no longer an intermediate ParenExpr, so we pick up the favored type.

Interestingly, there is logic in ConstraintOptimizer to propagate favored types across parens, but it happens after favorMatchingOverloadExprs. However, this means that the short-form constructor favoring logic in performMemberLookup has always been affected by this issue, for example on 5.5 this calls the optional init:

struct S {
  init(_ x: Int) { print("non-optional") }
  init(_ x: Int?) { print("optional") }
}

func foo(_ x: Int?) {
  let x = S(x ?? 0)
}

The argument list refactoring however opened this up to any unlabeled unary function call through favorMatchingOverloadExprs, not just for short-form constructor X(y) calls.

This patch fixes the above example for the ?? operator, but I wonder if there's more we should do here to mitigate the impact for user-defined operators? If we want to try and preserve the previous behavior, I guess we'd need to find a way not to run favorMatchingOverloadExprs for favored types computed by computeFavoredTypeForExpr. In general though it seems pretty worrying that computeFavoredTypeForExpr is run for arbitrary operators, maybe it should be limited to the stdlib's arithmetic operators? I'm not sure what kind of impact that would have tho.

[xedin]

@hamishknight Running this only for stdlib ones might be a good idea. We should remove the favoring from performMeberLookup too, it's not the right place for it anyway.