* Move `AvailabilitySpec` handling logic to AST, so they can be shared
between libParse and ASTGen
* Requestify '-define-availability' arguments parsing and parse them
with 'SwiftParser' according to the 'ParserASTGen' feature flag
* Implement 'AvailableAttr' generation in ASTGen
'ParserUnit' is used for analyzing syntax structures _mainly_ in
SourceKit.
Since we removed IfConfigDecl from AST, ParserUnit didn't
inclue any AST in #if ... #endif regions even for active region because
it used to consider all inactive. Instead, consider every region
"active" and include all the AST nodes.
rdar://117387631
Since resolving the domain of an `@available` attribute is done during type
checking now, diagnostics about unexpected versions for a domain need to be
emitted at that point instead of during parsing. It doesn't make sense to
maintain the special version of this diagnostic that is emitted during parsing
for the universal availability domain only.
Since the domain is now resolved by SemanticAvailableAttrRequest, diagnosing
attributes with invalid combinations of fields for a specific domains needs to
be delayed.
AvailableAttr::Kind and AvailabilityDomain are designed to replace
PlatformAgnosticAvailabilityKind, allowing AvailableAttr to more flexibly model
availability for arbitrary domains. For now, the new constructor just
translates its inputs into inputs for the existing constructor. Once all of the
callers of the existing AvailableAttr constructor have been updated to use the
new constructor, the representation of AvailableAttr will be updated to store
the new properties.
Introduce an `unsafe` expression akin to `try` and `await` that notes
that there are unsafe constructs in the expression to the right-hand
side. Extend the effects checker to also check for unsafety along with
throwing and async operations. This will result in diagnostics like
the following:
10 | func sum() -> Int {
11 | withUnsafeBufferPointer { buffer in
12 | let value = buffer[0]
| | `- note: reference to unsafe subscript 'subscript(_:)'
| |- warning: expression uses unsafe constructs but is not marked with 'unsafe'
| `- note: reference to parameter 'buffer' involves unsafe type 'UnsafeBufferPointer<Int>'
13 | tryWithP(X())
14 | return fastAdd(buffer.baseAddress, buffer.count)
These will come with a Fix-It that inserts `unsafe` into the proper
place. There's also a warning that appears when `unsafe` doesn't cover
any unsafe code, making it easier to clean up extraneous `unsafe`.
This approach requires that `@unsafe` be present on any declaration
that involves unsafe constructs within its signature. Outside of the
signature, the `unsafe` expression is used to identify unsafe code.
There’s a very easy to reach `llvm_unreachable()` in this code which ought to be a diagnostic, as well as a couple of other issues. Rework it into something that’s a bit better at handling the edge cases.
This attribute will allow you to specify an alternate version of the declaration used for mangling. It will allow minor adjustments to be made to declarations so long as they’re still compatible at the calling convention level, such as refining isolation or sendability, renaming without breaking ABI, etc.
The attribute is behind the experimental feature flag `ABIAttribute`.
The `@differentiable` and `@derivative` attributes need a parent pointer. Move the code to populate it from Parser to AST so it can be more easily shared between the parsers.
Done in preparation for similar code to be added for `@abi`.
Disable inference diagnostics because the AST output makes implicit initializers
explicit.
Enable parsing the @lifetime declaration syntax to handle explicit annotations
on declarations.
Introduce an attribute to allow unsafe code within the annotated
declaration without presenting an unsafe interface to users. This is,
by its nature, and unsafe construct, and is used to document where
unsafe behavior is encapsulated in safe constructs.
There is an optional message that can be used as part of an audit
trail.
Since the introduction of custom attributes (as part of property
wrappers), we've modeled the context of expressions within these
attributes as PatternBindingInitializers. These
PatternBindingInitializers would get wired in to the variable
declarations they apply to, establishing the appropriate declaration
context hierarchy. This worked because property wrappers only every
applied to---you guessed it!---properties, so the
PatternBindingInitializer would always get filled in.
When custom attributes were extended to apply to anything for the
purposes of macros, the use of PatternBindingInitializer became less
appropriate. Specifically, the binding declaration would never get
filled in (it's always NULL), so any place in the compiler that
accesses the binding might have to deal with it being NULL, which is a
new requirement. Few did, crashes ensued.
Rather than continue to play whack-a-mole with the abused
PatternBindingInitializer, introduce a new CustomAttributeInitializer
to model the context of custom attribute arguments. When the
attributes are assigned to a declaration that has a
PatternBindingInitializer, we reparent this new initializer to the
PatternBindingInitializer. This helps separate out the logic for
custom attributes vs. actual initializers.
Fixes https://github.com/swiftlang/swift/issues/76409 / rdar://136997841
Many APIs using nonescapable types would like to vend interior pointers to their
parameter bindings, but this isn't normally always possible because of representation
changes the caller may do around the call, such as moving the value in or out of memory,
bridging or reabstracting it, etc. `@_addressable` forces the corresponding parameter
to be passed indirectly in memory, in its maximally-abstracted representation.
[TODO] If return values have a lifetime dependency on this parameter, the caller must
keep this in-memory representation alive for the duration of the dependent value's
lifetime.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
The renamed decl is now stored exclusively in the split request evaluator
storage, which is more efficient since most availability attributes do not
specify a renamed decl.
Use `ExportedSourceFile.sourceLocationConverter.lineTable.virtualFiles`
to populate the information in `swift::SourceManger` and
`swift::SourceFile` when "parsing" with ASTGen
The previous logic for this was unused, replace
it with new logic that consults
InvertibleProtocols.def for the list of protocols
to suggest.
rdar://139212286
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
