Embedded Swift doesn't have protocol conformance metadata, so it cannot
handle dynamic casts to existentials (nor should it).
Another part of rdar://119383905.
Generic methods declared in protocols (and extensions thereof) cannot
be used on existential values, because there is no way to specialize
them for all potential types. Diagnose such cases in Embedded Swift
mode and via `-Wwarning EmbeddedRestrictions`.
This adds a bunch more warnings to the standard library that we'll
need to clean up, probably by `#if`'ing more code out.
Part of rdar://119383905.
Move the diagnostic about non-final generic methods in classes up to
the type checker, so that it is available to `-Wwarning
EmbeddedRestrictions` and earlier in the pipeline. The SIL version of
this is still available as a backstop.
Yet another part of rdar://133874555.
Untyped throws depends on existentials (`any Error`), and is therefore
not available in Embedded Swift. Introduce a diagnostic that diagnoses
any use of untyped throws, suggesting that one use typed throws
instead.
Make this an opt-in diagnostic enabled with `-Wwarning
EmbeddedRestrictions`, whether in Embedded Swift or not, using the
"default ignore" flag on these new warnings. Document this new
diagnostic group, and put the existing Embedded Swift error about
weak/unowned references in it as well.
Part of the general push to have the type checker identify code that
will not compile as Embedded Swift earlier, rdar://133874555.
When the CustomAvailability experimental feature is enabled, make it an error
to specify an unrecognized availability domain name. Also, add these
diagnostics to a diagnostic group so that developers can control their behavior
when they are warnings.
Resolves rdar://152741624.
Also make the titles and one line summaries a little more consistent (at
least for diagnsotic groups and upcoming language features, haven't gone
through the educational notes).
The migration to `MemberImportVisibility` can be performed mechanically by
adding missing import declarations, so offer automatic migration for the
feature.
Resolves rdar://151931597.
This matches send non sendable but importantly also makes it clear that we are
talking about something that doesn't conform to the Sendable protocol which is
capitalized.
rdar://151802975
The warnings that ClangImporter emits about issues it encounters while
importing declarations from Clang modules should all belong to a diagnostic
group so that users of `-warnings-as-errors` can control their behavior using
the compiler flags introduce with SE-0443. It's especially important that these
diagnostics be controllable since they are often caused by external
dependencies and therefore the developer may not have any control over whether
they are emitted.
The `#ClangDeclarationImport` diagnostic group is intentionally broad so that
developers have a way to control all of these diagnostics with a single
`-Wwarning` flag. I fully expect that we'll introduce finer-grained diagnostic
groups for some of these diagnostics in the future, but those groups should be
hierarchically nested under `#ClangDeclarationImport`, which is supported by
SE-0443.
Resolves rdar://150524204.
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.
