A protocol conformance can be ill-formed due to isolation mismatches
between witnesses and requirements, or with associated conformances.
Previously, such failures would be emitted as a number of separate
errors (downgraded to warnings in Swift 5), one for each witness and
potentially an extra for associated conformances. The rest was a
potential flood of diagnostics that was hard to sort through.
Collect all of the isolation-related problems for a given conformance
together and produce a single error (downgraded to a warning when
appropriate) that describes the overall issue. That error will have up
to three notes suggesting specific courses of action:
* Isolating the conformance (when the experimental feature is enabled)
* Marking the witnesses as 'nonisolated' where needed
*
The diagnostic also has notes to point out the witnesses/associated
conformances that have isolation problems. There is a new educational
note that also describes these options.
We give the same treatment to missing 'distributed' on witnesses to a
distributed protocol.
Since these different forms of documentation have a similar purpose,
and there's already some infrastructure for educational notes, unify all of
the diagnostics-related documentation in a single place.
We might consider unifying these ideas in the compiler as well, but
that's for another day.
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
* Add educational notes for multiple inheritance
* Update edu note by adopting reviewer suggestions
* Update userdocs/diagnostics/multiple-class-inheritance.md
Co-authored-by: Varun Gandhi <varun_gandhi@apple.com>
* Added Flyable protocol definition to example
* Apply suggestions from code review
Co-authored-by: Varun Gandhi <varun_gandhi@apple.com>
* Apply suggestions from code review
Co-authored-by: Xiaodi Wu <13952+xwu@users.noreply.github.com>
* Use consistent terminology
Co-authored-by: Xiaodi Wu <13952+xwu@users.noreply.github.com>
* Use utensils example as suggested by review
* Update title to Multiple Inheritance
* Apply suggestions from code review
Co-authored-by: Xiaodi Wu <13952+xwu@users.noreply.github.com>
* Rename file to match changed name
* Add more objects in protocol construction example
* Apply suggestions from code review
Co-authored-by: Xiaodi Wu <13952+xwu@users.noreply.github.com>
Co-authored-by: Varun Gandhi <varun_gandhi@apple.com>
Co-authored-by: Xiaodi Wu <13952+xwu@users.noreply.github.com>
* [Docs] Minor edits for educational note on PATs
* Adopt reviewer feedback on wording
Co-authored-by: Owen Voorhees <owenvoorhees@gmail.com>
* Revert a capitalization change
* [Docs] Further revisions based on reviewer feedback for educational note on PATs
Co-authored-by: Owen Voorhees <owenvoorhees@gmail.com>
"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
Introduce an educational note with a synopsis of the build* function
declarations one can add to a function builder, and associate it with
the diagnostics indicating incorrect or missing build* functions.
Apply suggestions from code review
Co-authored-by: Ben Rimmington <me@benrimmington.com>
Reword explanation of pre-5.3 behavior
Associate SE-0286 note with warning diagnostic
