@_preInverseGenerics(except: <inverses>) is an extension of the existing
@_preInverseGenerics attribute that provides selective control over which
inverse requirements are mangled into a declaration's symbol name.
While the bare @_preInverseGenerics strips all inverse constraints
(~Copyable and ~Escapable) from mangling, the 'except:' form allows specific
inverses to be retained. This is needed when a type like Span already had
~Copyable mangled into its ABI-stable symbols and now needs to retroactively
adopt ~Escapable without changing those existing symbols. You can now express
that with `@_preInverseGenerics(except: ~Copyable)` to strip-out every inverse
except ~Copyable to preserve the pre-existing ~Copyable-containing symbols.
It requires the new experimental feature `PreInverseGenericsExcept`.
rdar://176395527
When a diagnostic belongs to a group that has a parent group (`GROUP_LINK` in `DiagnosticGroups.def`), display the full inheritance chain in the diagnostic output, including documentation hyperlinks and footnotes for each.
For example, a diagnostic in `ExistentialType` (child of `PerformanceHints`) now renders as:
```
warning: ... [#PerformanceHints::ExistentialType]
```
Groups without parents continue to display as before (`[#DeprecatedDeclaration]`).
Resolves rdar://170805800
Use closure for defer body
Revert to main
Rework implementation to keep FuncDecl
Add AST briding
Add test with async let
Add main actor tests
Add additional tests
Introduce new syntax for parsing arbitrary integer literal expressions for generic value arguments:
```swift
InlineArray<(<Expr>), T>
[(<Expr>) of T]
```
Which, for now, will co-exist alongside the current syntax of simple integer literals.
Replace `IntegerTypeRepr` with `GenericArgumentExprTypeRepr`, a new `TypeRepr` node that wraps arbitrary expressions in generic argument positions (e.g., `InlineArray<(1 + 3), Int>`). The node tracks resolution state, distinguishing whether the expression resolved to a type or an integer value.
Key changes:
- Parse parenthesized generic arguments as expressions
- Recover and distinguish types from integer expressions in `resolveGenericArgumentExprTypeRepr`.
- When the `LiteralExpressions` feature is enabled, type-check and constant-fold expressions to integer values
- Extract `PreCheckTarget` into a public header to expose `simplifyTypeExpr` for use during type resolution
Resolves rdar://168005391
Replaces the other ExperimentalLanguageFeature (non-plural) SPI usages with the plural version. Also removes the `@_spi` flag from BodyMacroWithControlFlow as body macros are no longer an experimental feature. This is liked to a PR on swift-syntax: https://github.com/swiftlang/swift-syntax/pull/3272
To a function type's lifetimes, a base version of the type is first created with
no lifetime dependence info. This is then passed to the dependence checker, and
the resulting dependencies are added to it.
It would be possible to do this analysis by passing just the parameter list and
result type (which are available before the type is created), but this approach
lets us avoid dealing with a header inclusion cycle between Types.h, ExtInfo.h,
and LifetimeDependence.h, since it does not require AnyFunctionType::Param to be
defined in LifetimeDependence.h.
A protocol that's been reparented declares it
by writing `@reparented` in its inheirtance clause
for each new parent. You can introduce a `@reparented`
parent to a pre-existing ABI-stable protocol's
inheritance hierarchy.
Only protocols declared to be `@reparentable` can be
used to reparent other protocols. Adding or removing
the `@reparentable` attribute is ABI-breaking, as it
effects the type metadata layout. Thus, reparentable
protocols must be born as such to use them with
protocols that are already ABI-stable.
This set of changes does not include the actual
implementation of ABI-stable reparenting.
For now, we write `read`/`modify` to .swiftinterface files
so they can be read by the draft implementation in current
compilers. Here are some of the issues:
* We _cannot_ support `read`/`modify` in Swift sources without
the user specifying a flag. That's because the idiom below occurs
in real code, and would be broken by such support. So when
we enable the `CoroutineAccessors` flag by default, we _must_
not support `read`/`modify` as accessor notations in source.
```
struct XYZ {
// `read` method that takes a closure
func read(_ closure: () -> ()) { ... }
// getter that uses the above closure
var foo: Type {
read { ... closure ... }
}
}
```
* .swiftinterface files don't have the above problem.
Accessor bodies aren't stored at all by default, and
when inlineable, we always write explicit `get`.
So we can continue to accept `read`/`modify` notation
in interface files.
So our strategy here is:
* We'll accept both `read`/`modify` and `yielding borrow`/`yielding mutate`
in interface files for a lengthy transition period.
* We'll write `read`/`modify` to swiftinterface files for
a little longer, then switch to `yielding borrow`/`yielding mutate`.
* We'll disable `read`/`modify` support in source files
when we enable `CoroutineAccessors` by default.
(We can't even diagnose, due to the above idiom.)
This means that early adopters will have to update their sources
to use the new terminology. However, swiftinterface files
will be exchangeable between the new and old compilers for a little
while.
This experimental feature allows you to override the default behavior
of a 'get' returning a noncopyable type, so that it returns an owned
value rather than a borrow, when that getter is exposed in opaque
interfaces like protocol requirements or resilient types.
resolves rdar://157318147
This does not rename all the internal variables, functions, and types
whose names were based on the old syntax.
I think it adds new syntax support everywhere it's needed while
retaining enough of the old syntax support that early adopters will
see nice deprecation messages guiding them to the new syntax.
Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
Allow external declaration of global variables via `@_extern(c)`. Such
variables need to have types represented in C (of course), have only
storage (no accessors), and cannot have initializers. At the SIL
level, we use the SIL asmname attribute to get the appropriate C name.
While here, slightly shore up the `@_extern(c)` checking, which should
fix issue #70776 / rdar://153515764.
The Swift 6.2 compiler emits spurious warnings about retroactive conformances
to protocols that are inherited through a protocol that is written module
qualified in the inheritance clause. Suppress the warnings by making the
inherited conformances explicit and module qualified.
The Swift 6.2 compiler has a bug where it diagnoses inherited conformances as
retroactive even if they are inherited through a protocol that has been written
module-qualified in the inheritance list. Work around this bug to avoid
superflous warnings.
NFC.
With this patch, I'm flipping the polarity of things.
The flag `-enable-experimental-feature ManualOwnership` now turns on the diagnostics,
but they're all silenced by default. So, you need to add -Wwarning or -Werror to
your build settings to turn on the specific diagnostics you care about.
These are the diagnostic groups relevant to the feature:
- SemanticCopies aka "explicit copies mode"
- DynamicExclusivity
For example, the build setting `-Werror SemanticCopies` now gives you errors about
explicit copies, just as before, but now you can make them just warnings with -Wwarning.
To opt-out a declaration from everything when using the feature, use @_noManualOwnership.
@_manualOwnership is no longer an attribute as a result.
resolves rdar://163372569
Removes the underscored prefixes from the @_section and @_used attributes, making them public as @section and @used respectively. The SymbolLinkageMarkers experimental feature has been removed as these attributes are now part of the standard language. Implemented expression syntactic checking rules per SE-0492.
Major parts:
- Renamed @_section to @section and @_used to @used
- Removed the SymbolLinkageMarkers experimental feature
- Added parsing support for the old underscored names with deprecation warnings
- Updated all tests and examples to use the new attribute names
- Added syntactic validation for @section to align with SE-0492 (reusing the legality checker by @artemcm)
- Changed @DebugDescription macro to explicitly use a tuple type instead of type inferring it, to comply with the expression syntax rules
- Added a testcase for the various allowed and disallowed syntactic forms, `test/ConstValues/SectionSyntactic.swift`.
.swiftinterface sometimes prints a pattern binding initializer and the
accessor block. However the parser doesn't expect such constructs and
the disambiguation from trailing closures would be fragile. To make it
reliable, introduce a disambiguation marker `@_accessorBlock` .
`ASTPrinter` prints it right after `{` only if 1) The accessor block is
for a pattern binding declaration, 2) the decl has an initializer
printed, and 3) the non-observer accessor block is being printed. In the
parser, if the block after an initializer starts with
`{ @_accessorBlock`, it's always parsed as an accessor block instead of
a trailing closure.
rdar://140943107
A PatternBindingEntry formed from a MissingPatternSyntax has no valid SourceLocs in it, and a PatternBindingDecl containing only PatternBindingEntries with no valid SourceLocs trips an assertion during availability checking. (Generating dummy SourceLocs can cause invalid overlaps between AvailabilityScopes, so that’s not a workable solution.) The fix is to:
• Refuse to generate a PatternBindingEntry from a PatternBindingSyntax with a MissingPatternSyntax (MissingPatternSyntaxes at nested positions don’t have this problem)
• Refuse to generate a PatternBindingDecl with no PatternBindingEntries
This ensures that the invalid AST nodes are never formed.
No current test cases hit this problem, but certain invalid module selector tests can run into this situation when run with ASTGen.
Kavon Farvardin
Artem Chikin
Doug Gregor
Konrad Malawski
Cal Stephens
Pavel Yaskevich
Allan Shortlidge
Frederick Kellison-Linn
Hunter Baker
Aidan Hall
Slava Pestov
elsa
Elsa Keirouz
Tim Kientzle
bashir
Daniil Kovalev
Kuba (Brecka) Mracek
Becca Royal-Gordon
Rintaro Ishizaki