[Sema] Perform availability checks in literals initializers

[LucianoPAlmeida]

Some literal initializers were not being handled in ExprAvailabilityWalker which make then being left undiagnosed in cases like:

struct Foo {}

@available(*, deprecated)
extension Foo: ExpressibleByStringLiteral {
    init(stringLiteral value: StringLiteralType) { }
}

let a: Foo = Foo(stringLiteral: "") // warning: 'init(stringLiteral:)' is deprecated
let b: Foo = "" // no warning

So this adds check for all literals that have an associated implicit initializer and collection literal as well.

Fixes #61564

[LucianoPAlmeida]

@swift-ci Please test

[hamishknight]

Thanks! I think we probably ought to apply this logic to the result type of the literal too, but I'm happy for that to be done in a follow up if you want. cc @tshortli in case he has any other comments.

[hamishknight]

I wonder if this is something that ought to be applied to the result type of a literal in general. e.g for:

@available(*, unavailable)
struct S: ExpressibleByIntegerLiteral {
  init(integerLiteral value: Int) {}
}
@available(*, unavailable)
typealias IntegerLiteralType = S

let i = 0

We're implicitly forming a call to S(integerLiteral: 0), but aren't erroring that it's unavailable.

[tshortli]

A long term goal of mine is to run availability checks on the transformed AST so that we can catch these issues in a more generalized way. Not sure if that applies directly here but it seems like it might.

[hamishknight]

Yeah these literal cases are tricky because we don't actually form the call in the AST, we emit them directly in SILGen

[LucianoPAlmeida]

I wonder if this is something that ought to be applied to the result type of a literal in general.

I'll create an issue to track that case and look at it separately =]

[LucianoPAlmeida]

@hamishknight @tshortli Issue created #61890

[hamishknight]

I love the thoroughness of this test, thanks!