For now the semantics provided by `@extensible` keyword on per-enum
basis. We might return this as an upcoming feature in the future with
a way to opt-out.
Instead of using the `isolated P` syntax, switch to specifying the
global actor type directly, e.g.,
class MyClass: @MainActor MyProto { ... }
No functionality change at this point
To pave the way for the new experimental feature which will operate on '@const' attribute and expand the scope of what's currently handled by '_const' without breaking compatibility, for now.
Allow a conformance to be "isolated", meaning that it stays in the same
isolation domain as the conforming type. Only allow this for
global-actor-isolated types.
When a conformance is isolated, a nonisolated requirement can be
witnessed by a declaration with the same global actor isolation as the
enclosing type.
When `ExtensibleEnums` flag is set, it's going to be reflected in
the module file produced by the compiler to make sure that consumers
know that non-`@frozen` enumerations can gain new cases in the
future and switching cannot be exhaustive.
* Collect flag in `ParamDecl::setTypeRepr()`.
* [ASTGen] Separate `BridgedParamDecl.setTypeRepr(_:)` from
`BridgedParamDecl.createParsed(_:)` aligning with C++ API. The majority
of the creations don't set the typerepr.
* Update `ParamSpecifierRequest::evaluate` to handle non-implicit
`ParamDecl` without `TypeRepr` (i.e. untyped closure parameter), instead
of `setSpecifier(::Default)` manually in Parse.
* Instead of hoisting VarDecl in the bridging functions, do it in
ASTGen.
* Introduce `Decl::forEachDeclToHoist` to handle VarDecls in
PatternBindingDecl, and EnumElementDecl in EnumCaseDecl.
* Intorduce `withBridgedSwiftClosure(closure:call:)` as a callback
mechanism between Swift and C++
* In `generate(sourceFile:)`, instead of using `generate(codeBlockItem:)`
handle `CodeBlockItemSyntax.Item` manually to handle `TLCD` wrapping
and `VarDecl` hoisting.
* Make `generate(variableDecl:)` handle TLCD correctly.
There are a few places in the AST where we use `uint64_t` as
`ArrayRef`'s size type. Even though of these `uint64_t` size fields are
actually defined as bitfields with a maximum value of 32, but
unfortunately it's not taken into account and clang complains about
the implicit cast.
The same attempt was made in 073905b573,
but several new places were added since then.
https://github.com/swiftlang/swift/pull/72659 turned out to have some
source compatibility fallout that we need to fix. Instead of introducing
yet another brittle compatibility hack, stop emitting errors about a
missing `any` altogether until a future language mode.
Besides resolving the compatibility issue, this will encourage
developers to adopt any sooner and grant us ample time to gracefully
address any remaining bugs before the source compatibility burden
resurfaces.
A subsequent commit adds a diagnostic group that will allow users to
escalate these warnings to errors with `-Werror ExistentialAny`.
When a function declaration has a body, its source range ends at the
closing curly brace, so it includes the `throws(E)`. However, a
protocol requirement doesn't have a body, and due to an oversight,
getSourceRange() was never updated to include the extra tokens
that appear after `throws` when the function declares a thrown
error type. As a result, unqualified lookup would fail to find a
generic parameter type, if that happened to be the thrown type.
Fixes rdar://problem/143950572.
ASTDumper was never updated to print extra conformance information,
like suppression, preconcurrency, etc. In default mode, we print it
as a comma-delimited list of source-like strings. In JSON mode, we
print objects containing flags.
When diagnosing a declaration that is more available than its context, to
preserve source compatibility we need to downgrade the diagnostic to a warning
when the outermost declaration is an extension. This logic regressed with
https://github.com/swiftlang/swift/pull/77950 and my earlier attempt to fix
this (https://github.com/swiftlang/swift/pull/78832) misidentified what had
regressed.
Really resolves rdar://143423070.
As specified by the SE-0446 acceptance, extensions that declare a type's
conditional `Copyable` or `Escapable` ability must reiterate explicitly all
of the `Copyable` and/or `Escapable` requirements, whether required or not
required (by e.g. `~Copyable`) that were suppressed in the original
type declaration.
Put AvailabilityRange into its own header with very few dependencies so that it
can be included freely in other headers that need to use it as a complete type.
NFC.
Extend the module trace format with a field indicating whether a given
module, or any module it depends on, was compiled with strict memory
safety enabled. This separate output from the compiler can be used as
part of an audit to determine what parts of Swift programs are built
with strict memory safety checking enabled.
