TypeCheckType: Make ExistentialAny warn rather than error until Swift 7

[AnthonyLatsis]

This enables programmers to opt in to assisted adoption of the new syntax without breaking code and, thus, migrate in increments, whilst retaining the option to unconditionally escalate warnings with -Werror.

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

#78398 makes the escalation actually work.

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

@slavapestov ping

[MahdiBM]

I'm not super opposed to this but I'm also not sure if the change is of much value.

I've been using the existential-any flag pretty much in every project since Swift 5.8 (or was it 5.7), and I've never encountered a situation where fixing the code isn't trivial. IIRC in almost all cases the compiler also properly tells you what to do to fix, a lot of times you can just accept the proposed FIXIT.

If one doesn't want to guard their code against not using existential-any, then they could have just not enabled the flag. If they have enabled the flag, then fixing things is trivial so I'm not sure what a downgrade to warning achieves in practice.

The only value I can see for this change is for the cases where existential-any is being buggy and is throwing an incorrect error.
I think enumerator-macro is actually encountering such an issue right now on nightlies. But then that's a bug to fix, not to ignore, and it doesn't sound like this was the reason for the proposed change either.

/__w/enumerator-macro/enumerator-macro/Sources/EnumeratorMacroImpl/Types/WithNormalizedTypeName.swift:8:28: error: use of protocol 'WithNormalizedTypeName' as a type must be written 'any WithNormalizedTypeName'
 6 | func bestEffortTypeName<T>(_ type: T.Type = T.self) -> String {
 7 |     switch type {
 8 |     case let customType as WithNormalizedTypeName.Type:
   |                            `- error: use of protocol 'WithNormalizedTypeName' as a type must be written 'any WithNormalizedTypeName'
 9 |         customType.normalizedTypeName
10 |     default:

(The error is unfixable btw, no variation of using/not-using any satisfies the compiler)

[AnthonyLatsis]

@MahdiBM I am going to post a more detailed motivation on the forums soon. Let’s defer the discussion until then. I will leave a link here.

(The error is unfixable btw, no variation of using/not-using any satisfies the compiler)

What’s the compiler where this is unfixable? any WithNormalizedTypeName.Type works on main.

[MahdiBM]

I tried to compile that project again and it does appear that the recent 6.1 / main toolchains don't have that problem anymore so I guess we're good now. But what I described did use to be the case.

[AnthonyLatsis]

https://forums.swift.org/t/downgrade-existential-any-errors-to-warnings-until-a-future-language-mode/77477

[AnthonyLatsis]

Superseded by #78459.