[Diagnostics] Fix Confusing Protocol Diagnostic

[OnyekachiSamuel]

What's in this pull request

• Update the diagnostic error message
• Add educational notes to explain better the error condition

Resolves SR-13039
Resolves: rdar://problem/64517054

[OnyekachiSamuel]

@hborla Kindly take a look, thanks.

[varungandhi-apple]

Apologies for only mentioning Error as a special case in the SR. I didn't realize there were other special cases too. 😅

[xwu]

Educational notes are written in a didactic style that starts from most general to specific.

I'd suggest taking a look at the related note about protocols with associated types, which starts off with an introduction that's very relevant here:

Protocols in Swift may be used as types

Perhaps something like the following text would be helpful:

Protocols in Swift may be used as types, but a protocol type (sometimes called an 'existential type') does not conform to its own protocol.

Because this particular question has been asked many times, you can find several different explanations on the Swift Forums. It might be helpful to see which ones seem to have the greatest clarity, and to reach out to those authors to see if they'd be willing to help contribute their work to this note.

[OnyekachiSamuel]

Thanks @xwu for the feedback, I will work on them.

[xwu]

Suggested change

	There is no implementation for for() used above.
	There is no implementation for `foo()` used above.

I think there's a rich set of real-world examples in the Swift Forums that users have stumbled on. Those can often be more valuable for teaching than a contrived example. I've been told that Swift documentation tries to avoid placeholder names in code examples like i, x, foo, instead preferring something more descriptive. Here, though, there's no semantics to be more descriptive about; I think it'd be much easier if we started from a real-world example someone has actually had trouble with, since any of those APIs would have real names and real semantics.

One simple example is probably enough, if it's well chosen. Having illustrated and described the issue, though (as I said to @owenv about the note on PATs), it can be helpful to show (at least briefly) what users who encounter this error should do instead. After all, they've got an error in their code, and they're here because they don't fully understand it. Here are some possible suggestions, but we should look to what the real-world examples tend to look like and try to see which ones are most frequently applicable:

In the case of an array, some users could use a homogeneous array instead; perhaps it'd have to be of type [Any], though. In some cases, users could (or even should) use generics. In the general case, however, users would need to create a manual type-eraser type; how to implement such a type would firmly be outside the scope of this note, however.

[hborla]

Thank you for your work on this!

[hborla]

@swift-ci please smoke test

[hborla]

@swift-ci please smoke test

[theblixguy]

It looks like there were three failures in the earlier test run:

06:37:27 Failing Tests (3):
06:37:27     Swift(linux-x86_64) :: compiler_crashers_fixed/00017-llvm-foldingset-llvm-attributesetnode-nodeequals.swift
06:37:27     Swift(linux-x86_64) :: compiler_crashers_2_fixed/0196-rdar48937223.swift
06:37:27     Swift(linux-x86_64) :: Sema/type_checker_crashers_fixed/rdar27830834.swift

@OnyekachiSamuel Could you fix the other two as well? They're also just diagnostic message adjustments.

[OnyekachiSamuel]

@swift-ci please smoke test

[theblixguy]

@OnyekachiSamuel Only people with commit access can trigger CI testing. The tests are still running, but you can push new changes and one of us could trigger the tests again for you once you’re ready.

[varungandhi-apple]

I don't think you'll be able to invoke CI, since access is typically granted after a few contributions. Once you're done updating the tests, please feel free to ping whoever is reviewing (in this case, you could @ any of us), and we can kick off the CI again for you.

Also, you've probably seen this, but if you haven't, you can use the --filter flag (both utils/run-test and lit.py support it) to run only selected tests when you are iterating on them locally, so you don't need to run all of them.

[OnyekachiSamuel]

I don't think you'll be able to invoke CI, since access is typically granted after a few contributions. Once you're done updating the tests, please feel free to ping whoever is reviewing (in this case, you could @ any of us), and we can kick off the CI again for you.

Also, you've probably seen this, but if you haven't, you can use the --filter flag (both utils/run-test and lit.py support it) to run only selected tests when you are iterating on them locally, so you don't need to run all of them.

Thanks @varungandhi-apple for informing me, I was not aware, thanks for the tips too 👍🏻.

[OnyekachiSamuel]

It looks like there were three failures in the earlier test run:

06:37:27 Failing Tests (3):
06:37:27     Swift(linux-x86_64) :: compiler_crashers_fixed/00017-llvm-foldingset-llvm-attributesetnode-nodeequals.swift
06:37:27     Swift(linux-x86_64) :: compiler_crashers_2_fixed/0196-rdar48937223.swift
06:37:27     Swift(linux-x86_64) :: Sema/type_checker_crashers_fixed/rdar27830834.swift

@OnyekachiSamuel Could you fix the other two as well? They're also just diagnostic message adjustments.

Sure, I will do that.

[hborla]

@swift-ci please smoke test

[varungandhi-apple]

Merged! 🎉 ⛵