This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
Using newer targets can lead to build failures, see
41c52889b9b87fc09dce
This has no effect currently, it is meant to support the switch
to `LLVM_ENABLE_RUNTIMES` to build compiler-rt -- #58465
Addresses rdar://99140817
Replace the correct Swift -> EarlySwiftSyntax dependency with an
EarlySwiftDriver -> EarlySwiftSyntax dependency, to keep a linear
dependency order in this part of the build graph.
When enabled, compile in support for round-trip testing the new
SwiftSyntax-provided Swift parser alongside the existing parser. Right
now, this means parsing every source file with the new parser and
ensuring that the resulting syntax tree can reproduce the input source
precisely. Over time, this is expected to grow.
Opt in to this behavior by passing the following to build-script:
build-script --early-swiftsyntax --extra-cmake-options=-DSWIFT_SWIFT_PARSER_MODE:STRING=ROUNDTRIP
Make libSyntax depend on swift-syntax: the new home for all
of this infrastructure. This greatly simplifies the addition and
amending of syntax nodes as only the swift-syntax paired with a
swift checkout will need to be changed. This is in contrast to
the existing build flow where a paired PR to both repos must be
made to change anything here.
Note that a paired PR may still be required if the legacy parser
needs to be adjusted in response to syntax nodes changing, but I
anticipate this to be a much more infrequent event now that
the C++ end of libSyntax is deprecated.
The current implementation currently requires to have physical machine
for each architecture supported by macOS, which is not desirable.
To allow all cases to be tested on a random Mac machine, allow
to inject an arbitratry current architecture into the inference
of the cross compile hosts by means of an environment variable.
Addresses rdar://99096874
With a properly prepared sysroot and toolchain file, these changes permit
cross-compilation of Swift as well as LLVM, CMark, and Dispatch (picking,
as usual, apple/swift-corelibs-libdispatch#556) from a Linux host
generating OpenBSD binaries.
The toolchain file must be specified as an environment variable to
`build-script` and discussion on how to properly set up the sysroot and
toolchain file will be handled later.
Similar to the way the early Swift Driver is built, introduce a
build-script option `--early-swiftsyntax` that uses the host Swift and
CMake to build the parts of the swift-syntax package that are expected
to become be used in the compiler.
Note that this does not obviate the need for the `--swiftsyntax`
option, because that build product uses the just-built Swift compiler
and SwiftPM to build, test, and install everything from the
swift-syntax package.
SequenceExprSyntax should have odd number elements. Previously 'a as b'
was parsed like:
```
(sequence_expr
(identifier_expr "a"),
(as_expr
'as'
(typeidentifier "b")))
```
So it had even number elements. Now it's parsed
```
(sequence_expr
(identifier_expr "a"),
(unresolved_as_expr 'as')
(type_expr
(typeidentifier "b")))
```
* [Build] Update scripts to use dyld_info
dyldinfo has been deprecated and will no longer be available on newer Xcode releases. It has been replaced with dyld_info. To stay compatible with older releases, we are still falling back to dyldinfo, if dyld_info is not available.
rdar://98570807
* Apply suggestions from code review
Co-authored-by: Guillaume Lessard <glessard@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Guillaume Lessard <glessard@users.noreply.github.com>
