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.
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
