Update the diagostic docs so that they can be built with docc:
* Add technologyroot (diagnostics.md) to aggregate all markdown files
* Fixed warnings in a few diagnostics docs
This allows the creation of docc documentation with a single
invocation of docc. It will generate the landing page from
diagnostics.md and include all of the diagnostics as subarticles.
The subarticles are accessible via the name of the markdown file,
which is being used as the ID for these diagnostics.
E.g. existential-any.
The docc docs for these documents can be generated locally with the
following command:
>docc preview --allow-arbitrary-catalog-directories userdocs/diagnostics
While here, fix some issues around implied isolated conformances (we
could get into an inconsistent state). Also provide an educational
note discussing isolated conformances and the kinds of errors one can
see when they are used from outside of their isolation domain.
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
