The bootstrapping stages were missing dependencies on the Concurrency
and Swift 5.6 backdeployment compatibility libraries resulting in
failing builds.
When using a unified LLVM + Swift build (using `LLVM_EXTERNAL_PROJECTS=swift`),
`CMAKE_SOURCE_DIR` is `llvm-project/llvm`, and appending `include/swift` to that directory doesn’t result in the directory that contains Swift’s header files.
Instead, look up the header files relative to `CMAKE_CURRENT_SOURCE_DIR`.
* "merge" the `Path` and `State` in WalkUtils into a single `WalkingPath`. This makes it simpler for clients to configure a path and additional state variables. EscapeInfo now defines `EscapePath` which includes the projection path and EscapeInfo's specific state variables.
* Make the `WalkerCache` part of the WalkUtils, so that not all clients have to re-implement it.
* Rename `walkDownResults` -> `walkDownAllResults` and `walkUpOperands` -> `walkUpAllOperands` and make these functions client configurable.
When using a unified LLVM + Swift build (using `LLVM_EXTERNAL_PROJECTS=swift`), swift is installed into `build_dir/tools/swift`. Thus, we also need to find the generated headers inside the `tools/swift/include` directory and not at the top-level `build_dir/include` directory.
This also removes `BridgedDiagnosticArgumentKind` in favor of `swift::DiagnosticArgumentKind`, bringing us one step closer to bridging the entire diagnostic engine via C++ interop.
rdar://83361087
These sets are _much_ more efficient than `Set<Value>` and `Set<Instruction>` because they bridge to the efficient `NodeSet`.
Insertions/deletions are just bit operations.
It's used to implement `InstructionSet` and `ValueSet`: sets of SILValues and SILInstructions.
Just like `BasicBlockSet` for basic blocks, the set is implemented by setting bits directly in SILNode.
This is super efficient because insertion and deletion to/from the set are basic bit operations.
The cost is an additional word in SILNode. But this is basically negligible: it just adds ~0.7% of memory used for SILInstructions.
In my experiments, I didn't see any relevant changes in memory consumption or compile time.
It needs to return nil in case the callee argument is not really applied by the ApplySite.
This fixes a crash in EscapeInfo when handling "escaping-to" effects:
If the callee operand of an apply instruction is a `partial_apply` of a `function_ref`, the callee-analysis looks through the `partial_apply` and we get the referenced function as a callee.
In this case there are less apply arguments than callee arguments, because the `partial_apply` already "applies" some of the callee arguments.
rdar://96830171
`EscapeInfo` now conforms to the generic protocols defined in `WalkUtils`.
This simplifies the implementation a bit, since trivial instructions are handled
by `WalkUtils` and `EscapeInfo` only has to handle a subset of instructions
inherent to escape information.
Passes using `EscapeInfo` are updated accordingly to become visitors that
customize the `EscapeInfo` walk.
Introduces a set of protocols useful to perform def-use and use-def
traversals to find uses and definitions of values.
This logic was originally baked into `EscapeInfo` directly.
Here we extract it into general utilities, namely:
- `ValueDefUseWalker`: visit uses of a value walking down value-value projections/constructions.
- `AddressDefUseWalker`: visit uses of an address walking down addr-addr projections/constructions.
- `ValueUseDefWalker`: visit definitions of a value walking up value-value projections/constructions.
- `AddressUseDefWalker`: visit definitions of an address walking up addr-addr projections/constructions.
These utilities can then be used in other passes or to create
new utilities by composing them. For example to find a definition
passing through both address projections and value extractions,
it's enough to implement a visitor conforming to both
`AddressUseDefWalker` and `ValueUseDefWalker`.
C++ interop is now enabled in SwiftCompilerSources, so we can remove some of the C bridging layer and use C++ classes directly from Swift.
rdar://83361087
Removes redundant ObjectiveC <-> Swift bridging calls.
Basically, if a value is bridged from ObjectiveC to Swift an then back to ObjectiveC again, then just re-use the original ObjectiveC value.
Also in this commit: add an additional DCE pass before ownership elimination. It can cleanup dead code which is left behind by the ObjCBridgingOptimization.
rdar://89987440
To use new C++ interop features in SwiftCompilerSources, we need a very recent Swift compiler when building with host tools.
This does not affect non-HOSTTOOLS builds.
To use _RegexParser from SwiftSyntax.
* Create 'libswiftCompilerModules_SwiftSyntax.a' which is a subset of
'libswiftCompilerModules.a'
* Link 'lib_InternalSwiftSyntaxParser' to
'libswiftCompilerModules_SwiftSyntax.a'
* Factor out swift runtime linking logic in CMake so that dynamic
libraries can link to Swift runtime, in addition to executables
* Link 'lib_InternalSwiftSyntaxParser' to swift runtime
Some code in SwiftCompilerSources, especially the parts that use C++ interop, triggers bugs in older versions of the Swift compiler. To make sure that `HOSTTOOLS` builds don't produce obscure compiler errors or crashes, let's require a relatively new Swift compiler for `HOSTTOOLS` build.
This fixes a dangling pointer issue when creating a `Swift.String` from `std::string`.
Also fixes a warning:
```
warning: variable 's' was never mutated; consider changing to 'let' constant
var s = SILBasicBlock_debugDescription(bridged)
~~~ ^
let
```
rdar://92963081
rdar://93053488
