Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.
* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
`lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
This has one `swift_inproc_plugins_handle_message` entry point that
receives a message and return the response.
* In the compiler
* Add `-in-process-plugin-server-path` front-end option, which specifies
the `SwiftInProcPluginServer` shared library path.
* Remove `LoadedLibraryPlugin`, because all library plugins are managed
by `SwiftInProcPluginServer`
* Introduce abstract `CompilerPlugin` class that has 2 subclasses:
* `LoadedExecutablePlugin` existing class that represents an
executable plugin
* `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
* Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
difference between executable plugins and library plugins are now
abstracted by `CompilerPlugin`
We treated enum case parameters the same way as function parameters and weren’t considering that they can be unlabeled. That caused us to insert eg. `_ ` in front of the case’s type, producing `case myCase(_ String)`, which is invalid. When we are inside an enum case parameter and the parameter label is empty, treat it the same as a function call, which will leave the label untouched if it isn’t modified and insert a label including a colon if a new label is introduced.
https://github.com/apple/sourcekit-lsp/issues/1228
Use the correct source file.
Previously, the location of declaration macros were sent to executable
plugins as if the were in the source file of the attribute. This was
problematic when the attribute is synsthesized by a macro. When source
location were used in the plugin, for example, as a diagnostic location,
it ended up with an unknown location.
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
`macro` declarations often appear in files that does not contain any
expansions (e.g. `.swiftinterface`). So invoking `SwiftParser` for the
entire file is a waste.
The attribute declares that a struct contains "sensitive" data.
It enforces that the contents of such a struct value is zeroed out at the end of its lifetime.
In other words: the content of such a value is not observable in memory after the value's lifetime.
Also add an experimental feature `Sensitive` with which the attribute can be enabled.
We see some crashes presumably caused by invalid 'offset' returned from
macro plugins. Although we haven't been able to find a reproducer, guard
not to generate invalid source location by checking 'offfset' is within
the buffer length.
rdar://125625879
Rather than adding custom parsing to SwiftSyntax, we can parse this as a custom attribute and convert it to a built-in one in ASTGen. Test that this works correctly (and fix a bug where it wasn’t).
Our standard conception of suppressible features assumes we should
always suppress the feature if the compiler doesn't support it.
This presumes that there's no harm in suppressing the feature, and
that's a fine assumption for features that are just adding information
or suppressing new diagnostics. Features that are semantically
relevant, maybe even ABI-breaking, are not a good fit for this,
and so instead of reprinting the decl with the feature suppressed,
we just have to hide the decl entirely. The missing middle here
is that it's sometimes useful to be able to adopt a type change
to an existing declaration, and we'd like older compilers to be
able to use the older version of the declaration. Making a type
change this way is, of course, only really acceptable for
@_alwaysEmitIntoClient declarations; but those represent quite a
few declarations that we'd like to be able to refine the types of.
Rather than trying to come up with heuristics based on
@_alwaysEmitIntoClient or other sources of information, this design
just requires the declaration to opt in with a new attribute,
@_allowFeatureSuppress. When a declaration opts in to suppression
for a conditionally-suppressible feature, the printer uses the
suppression serially-print-with-downgraded-options approach;
otherwise it uses the print-only-if-feature-is-available approach.
To maintain source compatibility, SE-0352 does not open existentials
with "self-conforming" type, such as `any Error` or existentials based
on `@objc` protocols. The proposal specified that this behavior would
change in Swift 6. Implement that behavior change, which can be
enabled prior to Swift 6 with the upcoming feature
`ImplicitOpenExistentials` (as documented in SE-0362).
Fixes#70873 / rdar://120902975.
[transferring] Implement transferring result and clean up transferring param support by making transferring a bit on param instead of a ParamSpecifier.
Instead it is a bit on ParamDecl and SILParameterInfo. I preserve the consuming
behavior by making it so that the type checker changes the ParamSpecifier to
ImplicitlyCopyableConsuming if we have a default param specifier and
transferring is set. NOTE: The user can never write ImplicitlyCopyableConsuming.
NOTE: I had to expand the amount of flags that can be stored in ParamDecl so I
stole bits from TypeRepr and added some logic for packing option bits into
TyRepr and DefaultValue.
rdar://121324715
And remove the `-disable-experimental-parser-round-trip` flag from borrowing
switch tests now that the SwiftSyntax parser supports them with
https://github.com/apple/swift-syntax/pull/2487.
