Lifetime indices are never necessary in Swift, they unnecessarily expose
implementation details, and they make lifetime annotations more error-prone,
since they may need to be updated if a function's parameter list changes.
The Swift Syntax parser also cannot handle lifetime annotations where the target
is an index. The main reason the C++ parser supports them is because it is also
used for SIL.
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.
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.
Some Darwin platforms like DriverKit use a system prefix on all of their search paths. Even though DriverKit isn't supported, add support to get the system prefix from SDKSettings when constructing the default search paths.
This requires the DarwinSDKInfo to be gotten earlier in CompilerInvocation, pass that down to ASTContext through CompilerInstance.
-platform-availability-inheritance-map-path is no longer needed to support visionOS in tests, remove that and its supporting code that gets an alternative DarwinSDKInfo.
rdar://166277280
This implements two approaches for specifying derivatives of
yielding mutate and borrow accessors:
1. Using backticks to specify a yielding accessor:
```
// expected-note @+1 {{cannot register derivative for yielding borrow accessor}}
var computedProperty2: T {
yielding borrow { yield x }
yielding mutate { yield &x }
}
// expected-error @+1 {{referenced declaration 'computedProperty2' could not be resolved}}
@derivative(of: computedProperty2.`yielding borrow`)
mutating func vjpPropertyYieldingBorrow(_ newValue: T) -> (
value: (), pullback: (inout TangentVector) -> T.TangentVector
) { ... }
```
This requires it to be spelled with exactly one space.
2. Use .borrow or .mutate and resolve in Sema:
```
// expected-note @+1 {{cannot register derivative for yielding borrow accessor}}
var computedProperty2: T {
yielding borrow { yield x }
yielding mutate { yield &x }
}
// expected-error @+1 {{referenced declaration 'computedProperty2' could not be resolved}}
@derivative(of: computedProperty2.borrow)
mutating func vjpPropertyYieldingBorrow(_ newValue: T) -> (
value: (), pullback: (inout TangentVector) -> T.TangentVector
) { ... }
```
In order to support the latter, I've had to refactor the
resolution for these names so that error messages can show
the type (e.g., "yielding borrow") of the actual resolved
accessor, even if that's different from the specification.
This updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
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.
We don't have support for borrowing switch on Copyable types.
It is supported for ~Copyable types, but the return expression emission for borrow accessors is not yet implemented.
Diagnose instead of crashing the compiler.
Otherwise these source file objects linger in the source manager but they refer to a fully-temporary 'ASTContext' which does not exist after parsing is complete, which means they cannot be used in any way and attempting to do so would lead to a crash.
Lexer should always set `Token.CommentLength` correctly because it
necessary for restoring to the token position with comments.
Otherwise, 'Token::isAtStartOfLine()' might not correctly set.
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.
Currently, normal globals are represented as a PatternBindingDecl and a VarDecl in the AST, directly under the SourceFile:
```
// var variable_name = 42, compiled with -parse-as-library
(source_file ...
(pattern_binding_decl ...
(pattern_entry ...
(pattern_named ... "variable_name") ...
(var_decl "variable_name" ...
```
Top-level globals are represented more like local variables, under a TopLevelCodeDecl. Note that the VarDecl is still at the file scope. In SILGen, this case has some special handling to use the a storage of a global variable, and to avoid cleanups (see `emitInitializationForVarDecl`). Effectively, this means the globals are initialized inside the `main` function.
```
// var variable_name = 42, compiled without -parse-as-library
(source_file ...
(top_level_code_decl ...
(brace_stmt ...
(pattern_binding_decl ...
(pattern_named ... "variable_name") ...
(var_decl "variable_name" ... top_level_global
```
SE-0492 needs top-level globals that have a `@section` annotation to behave like a normal global -- initialization must happen statically, and not in `main`. This PR changes the parsing of those globals to match normal globals, without the TopLevelCodeDecl wrapper. SILGen and IRGen then handles them correctly.
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`.
The legacy parser has a special case for code like `fn(:)` which corrects it to `fn(_:)`, but the new `::` token was interfering with cases where there were two adjacent colons (e.g. `fn(::)`). Correct this issue.
.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
