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.
This is a new restriction that folks are sure to run into, so provide
it with some actionable documentation. Fixes rdar://152450956.
(cherry picked from commit 9f0dda5417)
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
(cherry picked from commit 3ed4059a60)
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.
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.
Parsing for `-enable-upcoming-feature` and `-enable-experimental-feature` is
lenient by default because some projects need to be compatible with multiple
language versions and compiler toolchains simultaneously, and strict
diagnostics would be a nuisance. On the other hand, though, it would be useful
to get feedback from the compiler when you attempt to enable a feature that
doesn't exist. This change splits the difference by introducing new diagnostics
for potential feature enablement misconfigurations but leaves those diagnostics
ignored by default. Projects that wish to use them can specify `-Wwarning
StrictLanguageFeatures`.
As an example, use this for the "`@preconcurrency` on import has no
effect" warning, which is not yet working correctly. This disables it
by default but leaves it in place for our testing.
This group has not shipped yet and was added mainly to support test
coverage for d56b7df8a9. Now that we have
unit tests for this, delete the group, pending discussion.
This change addresses the following issue: when an error is being wrapped in a warning, the diagnostic message will use the wrapper's `DiagGroupID` as the warning's name. However, we want to retain the original error's group for use. For example, in Swift 5, async_unavailable_decl is wrapped in error_in_future_swift_version. When we print a diagnostic of this kind, we want to keep the `DiagGroupID` of `async_unavailable_decl`, not that of `error_in_future_swift_version`.
To achieve this, we add `DiagGroupID` to the `Diagnostic` class. When an active diagnostic is wrapped in DiagnosticEngine, we retain the original `DiagGroupID`.
For illustration purposes, this change also introduces a new group: `DeclarationUnavailableFromAsynchronousContext`.
With this change, we produce errors and warnings of this kind with messages like the following:
```
global function 'fNoAsync' is unavailable from asynchronous contexts [DeclarationUnavailableFromAsynchronousContext]
global function 'fNoAsync' is unavailable from asynchronous contexts; this is an error in the Swift 6 language mode [DeclarationUnavailableFromAsynchronousContext]
```
This commit adds new compiler options -no-warning-as-error/-warning-as-error which allows users to specify behavior for exact warnings and warning groups.
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.
