Thread the static build configuration (formed from language options) in
to the macro plugin handler, which will serialize it for use in the
macro implementation. test this with a simple macro that checks
whether a particular custom configuration (set via `-D`) is enabled or
not.
This required some re-layering, sinking the logic for building a
StaticBuildConfiguration from language options down into a new
swiftBasicSwift library, which sits on top of the C++ swiftBasic and
provides Swift functionality for it. That can be used by the C++
swiftAST to cache the StaticBuildConfiguration on the ASTContext,
making it available for other parts of ASTGen.
When emitting diagnostics for the Embedded Swift restrictions outside
of Embedded Swift mode, consider `#if $Embedded` and `#if
hasFeature(Embedded)` configurations. If the code where we would emit
the diagnostic would be disabled in Embedded Swift by one of those
checks, don't emit the diagnostic. This helps code that can compile
either with Embedded or regular Swift stay within the restrictions on
Embedded Swift.
The diagnostics formatter from swift-syntax previously only handled
fully-formed diagnostics anchored at a particular syntax node.
Therefore, the compiler would fall back to the existing LLVM-based
diagnostic formatter for diagnostics that had no source location.
Adopt new API in the swift-syntax diagnostics formatter that renders a
diagnostic message without requiring source location information, so
that we consistently use the swift-syntax formatter when it is
selected (which is the default).
When printing diagnostics, category names are printed as [#<category-name>]
at the end of a diagnostic. For all of the category names that are mentioned
in this manner, print "footnotes" at the end of compilation providing
documentation references to each category, e.g.,
[#deprecated]: <http://example.com/deprecated>
[#StrictMemorySafety]: <http://example.com/memory-safety>
Right now, these point into the markdown files in the installed toolchain,
same as the URLs behind references. That is subject to change in the future.
Bridge the category name and educational note computed for the Swift
compiler's diagnostics to the newly-introduced category field for
the swift-syntax diagnostics. This lets the swift-syntax renderer
introduce the category name and (optionally) link to the
documentation.
Parse expanded buffer into dedicated syntax.
Also rename `BridgedGeneratedSourceFileKindAttribute` to
`BridgedGeneratedSourceFileKindAttributeFromClang` because C++ decl
(i.e. `GeneratedSourceInfo::Kind::AttributeFromClang`) was renamed a
while ago.
* 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
Use `ExportedSourceFile.sourceLocationConverter.lineTable.virtualFiles`
to populate the information in `swift::SourceManger` and
`swift::SourceFile` when "parsing" with ASTGen
Now that ASTGen should be able to generate most Swift code. Let's
remove "legacy parser" call-in, and remove the unhealthy cyclic
dependency between lib/Parse and ASTGen.
* Make ExportedSourceFile hold any Syntax as the root node
* Move `ExportedSourceFileRequest::evaluate()` to `ParseRequests.cpp`
* Pass the decl context and `GeneatedSourceFileInfo::Kind` to
`swift_ASTGen_parseSourceFile()` to customize the parsing
* Make `ExportedSourceFile` to hold an arbitrary Syntax node
* Move round-trip checking into `ExportedSourceFileRequest::evaluate()`
* Split `parseSourceFileViaASTGen` completely from C++ parsing logic
(in `ParseSourceFileRequest::evaluate()`)
* Remove 'ParserDiagnostics' experimental feature: Now that we have
ParserASTGen mode which includes the swift-syntax parser diagnostics.
Add the necessary compiler-side logic to allow
the regex parsing library to hand back a set of
features for a regex literal, which can then be
diagnosed by ExprAvailabilityWalker if the
availability context isn't sufficient. No tests
as this only adds the necessary infrastructure,
we don't yet hand back the features from the regex
parsing library.
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.
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`
`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.
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.
Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
* 'ASTGenVisitor' has a reference to a legacy C++ Parser configured for
ASTGen.
* If 'ASTGenVisitor' encounters a AST node that hasn't been migrated,
call parse(Decl|Stmt|Expr|Type) to parse the position using the legacy
parser.
* The legacy parser calls ASTGen's
'swift_ASTGen_build(Decl|Stmt|Expr|Type)' for each ASTNode "parsing"
(unless the call is not directly from the ASTGen.)
rdar://117151886
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
