Always run explicit `Sendable` checks on public types and suppress
warning printing by default instead of using a special compiler argument.
Resolves: rdar://162394810
Several changes:
- shorten the warning at the call-site of unannotated functions that
return FRTS
- place the call to action ("annotate 'X' with 'Y'") at the diagnostic
note attached to the unannotated callee, where the annotation should
be made
- re-word the foreign-reference-type.md documentation to (1) reflect the
diagnostic wording change, (2) give a little bit more background about
why the annotations are needed, and (3) not be specific to C++ (since
we can import FRTs from C as well)
This is mostly just cleanup:
1. Removes `diagnostic-descriptions.md` since it isn't used any more
2. Adds the group name to all the old notes files
3. Removes trailing whitespace
4. Adds "See Also" sections for notes that have links
- Delete baseline language feature WarnUnannotatedReturnOfCxxFrt,
which won't really be useful to users
- Remove some references to "cxx", since FRTs are not exclusively
imported from C++
- Clean up lit test RUN lines to use %{fs-sep}
This change makes the warning for unannotated C++ functions returning foreign
reference types (FRT) enabled by default, improving memory safety for Swift/C++
interop users. Also added CxxForeignReferenceType diagnostic group for better control
This check will run on each type-checked primary input of the current compilation and emit a warning diagnostic for all discovered occurences of this code pattern when the performance hint diagnostic is enabled
A "permanently enabled" availability domain is one that has been declared
always available and is also simultaneously has either an attribute that
makes it deprecated or universally unavailable.
Emit fix-its that remove (or update) `@available` attributes that restrict
availability in a permanently enabled domain. Also, emit warnings about
`if #available` queries that always return true because they check a
permanently enabled domain.
Resolves rdar://157601761.
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.
