Parse expanded buffer into dedicated syntax.
Also rename `BridgedGeneratedSourceFileKindAttribute` to
`BridgedGeneratedSourceFileKindAttributeFromClang` because C++ decl
(i.e. `GeneratedSourceInfo::Kind::AttributeFromClang`) was renamed a
while ago.
* Instead of hoisting VarDecl in the bridging functions, do it in
ASTGen.
* Introduce `Decl::forEachDeclToHoist` to handle VarDecls in
PatternBindingDecl, and EnumElementDecl in EnumCaseDecl.
* Intorduce `withBridgedSwiftClosure(closure:call:)` as a callback
mechanism between Swift and C++
* In `generate(sourceFile:)`, instead of using `generate(codeBlockItem:)`
handle `CodeBlockItemSyntax.Item` manually to handle `TLCD` wrapping
and `VarDecl` hoisting.
* Make `generate(variableDecl:)` handle TLCD correctly.
* 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
Previously, they were being parsed as top-level code, which would cause
errors because there are no definitions. Introduce a new
GeneratedSourceInfo kind to mark the purpose of these buffers so the
parser can handle them appropriately.
* 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.
`SWIFT_IMPORT_UNSAFE` is an escape hatch that can be used to make the Swift compiler ignore its usual safety heuristics for C++ types.
`BridgedOwnedString` fits into the definition of a self-contained C++ type in Swift: it manages the lifetimes of its own fields.
This removes the usages of `SWIFT_IMPORT_UNSAFE` for C++ functions that return `BridgedOwnedString`, and annotates `BridgedOwnedString` as a self-contained type.
Merge `$<Feature>` and `hasFeature` implementations.
- `$<Feature>` did not support upcoming language features.
- `hasFeature` did not support promoted language features and also
didn't take into account `Options` in `Features.def`.
Remove `Options` entirely, it was always one of three cases:
- `true`
- `langOpts.hasFeature`
- `hasSwiftSwiftParser`
Since `LangOptions::hasFeature` should always be used anyway, it's no
longer necessary. `hasSwiftSwiftParser` can be special cased when adding
the default promoted language features (by removing those features).
Resolves rdar://117917456.
Remove the default constructor footgun present with
the struct implementations, and sprinkle some
`SWIFT_NAME` and bridging utilities to make them
nicer to work with.
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
Introduce a macro that can stamp out wrapper
classes for underlying C++ pointers, and use
it to define BridgedDiagnosticEngine in
ASTBridging. Then, migrate users of
BridgedDiagEngine onto it.
Introduce two modes of bridging:
* inline mode: this is basically how it worked so far. Using full C++ interop which allows bridging functions to be inlined.
* pure mode: bridging functions are not inlined but compiled in a cpp file. This allows to reduce the C++ interop requirements to a minimum. No std/llvm/swift headers are imported.
This change requires a major refactoring of bridging sources. The implementation of bridging functions go to two separate files: SILBridgingImpl.h and OptimizerBridgingImpl.h.
Depending on the mode, those files are either included in the corresponding header files (inline mode), or included in the c++ file (pure mode).
The mode can be selected with the BRIDGING_MODE cmake variable. By default it is set to the inline mode (= existing behavior). The pure mode is only selected in certain configurations to work around C++ interop issues:
* In debug builds, to workaround a problem with LLDB's `po` command (rdar://115770255).
* On windows to workaround a build problem.
