[SR-2705][Sema] Always favor non-autoclosure parameter function overload on ranking

[LucianoPAlmeida]

Implement a rule on ranking where overload choices that has @autoclosure parameters are disfavored over the ones that aren't to avoid ambiguity in situations like

func f<T>(_: () -> T) {}
func f<T>(_: @autoclosure () -> T) {}

f { } // ok

Resolves SR-2705.

[LucianoPAlmeida]

@swift-ci Please smoke test

[LucianoPAlmeida]

@swift-ci Please smoke test macOS platform

[LucianoPAlmeida]

@swift-ci Please smoke test Linux platform

[xedin]

I think CSRanking might be too big of a hammer here, how about we either increment an existing score kind i.e. SK_FunctionConversion or add a new kind to use specifically for situations when closure is an argument for autoclosure coversion?

[LucianoPAlmeida]

I think CSRanking might be too big of a hammer here, how about we either increment an existing score kind i.e. SK_FunctionConversion or add a new kind to use specifically for situations when closure is an argument for autoclosure coversion?

Thanks, I've updated and that indeed feels like a better solution :)

[xedin]

Definitely looks better now! I think we should add a new ScoreKind at the end of the list though to make sure that it doesn’t interfere in ranking too much since SK_FunctionConversion seems too high of a priority for this...

[LucianoPAlmeida]

I think we should add a new ScoreKind at the end of the list though to make sure that it doesn’t interfere in ranking too much since SK_FunctionConversion seems too high of a priority for this...

That makes sense, changes done :)

[xedin]

I think we are almost there just need a couple of final changes to tests.

[xedin]

Great work, thank you!

[LucianoPAlmeida]

@swift-ci Please smoke test

[xedin]

@swift-ci please test source compatibility debug

[LucianoPAlmeida]

Windows is failing, that may started before that #36107 was merged, let's try again

@swift-ci Please test Windows Platform

[LucianoPAlmeida]

Thanks @xedin!