The SwiftIfConfig library provides APIs for evaluating and extracting
the active #if regions in source code. Use its "configured regions" API
along with the ASTContext-backed build configuration to reimplement the
extraction of active/inactive regions from the source.
This approach has the benefit of being effectively stateless: where the
existing solution relies on the C++ parser recording all of the `#if`
clauses it sees as it is parsing (and then might have to sort them later),
this version does a scan of source to collect the list without requiring
any other state. The newer implementation is also conceptually cleaner,
and can be shared with other clients that have their own take on the
build configuration.
The primary client of this information is the SourceKit request that
identifies "inactive" regions within the source file, which IDEs can
use to grey out inactive code within the current build configuration.
There is also some profiling information that uses it. Those clients
should be unaffected by this under-the-hood change.
For the moment, I'm leaving the old code path in place for compiler
builds that don't have swift-syntax. This should be considered
temporary, and that code should be removed in favor of request'ifying
this function and removing the incrementally-built state entirely.
This concrete implementation of the BuildConfiguration allows the use of
the SwiftIfConfig library's APIs where the build configuration comes from
the compiler itself.
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
Out of an abundance of caution, we:
1. Left in parsing support for transferring but internally made it rely on the
internals of sending.
2. Added a warning to tell people that transferring was going to
be removed very soon.
Now that we have given people some time, remove support for parsing
transferring.
rdar://130253724
The issue is that the shorthand if let syntax injects an implicit
expression: https://github.com/apple/swift/pull/40694/ in ParseStmt and
that the 'diagnoseUnhandledAsyncSite' explicitly avoids reporting errors
in implicit expressions.
This change is that we don't mark the implicit declref code emitted by
the `if let prop` as implicit anymore, and this way the reporting works
out as expected.
Added some tests covering this as well as properly erroring out for the
nonexistent syntax of shortand + awaiting which doesn't exist, and we
properly error on it.
Resolves rdar://126169564
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.
