* Rename 'BuildRule to 'BuildEdige' because it is the official term
* NinjaParser to handle 'include' and 'rule' directives
* NinjaParser to handle parse "rule name" in 'build' correctly
* Make variable table a simple `[String: String]` and keep any bindings
to make the substitutions possible.
* Generate command line argumets using 'command' variable in the 'rule'
and use it as the source of truth, istead of using random known
bindings like 'FLAGS'.
TL;DR Please revert this patch in case LLDB testing on Windows clogs Swift PR-tests
The LLDB test suite is not very stable on Windows, which is a problem when we want to run them in CI. In order to improve the situation, however, we need to get it tested continuously. This patch attempts to solve the chicken-egg problem. It introduces a simple override for unstable tests: list them in file `utils/windows-llvm-lit-test-overrides.txt` and SwiftCI will skip/xfail them.
This approach has a number of benefits:
* overrides don't need to be in sync with https://github.com/swiftlang/llvm-project
* overrides are tracked in one place and they are not spread across the LLDB test suite
* overrides are swiftlang-specific, which clearly states the differences to upstream LLVM
* we can enable continuous testing (and get reports for new failures) without fixing the world first
Once the remaining subset of tests passes reliably, we can iterate to enable the others and increase coverage. My previous patch 459e59265d implemented the necessary infrastructure. This one only enable tests in CI. The separation allows to disable LLDB testing on Windows with fewer side-effects.
The LLDB test suite is not very stable on Windows. In order to improve the situation, however, we need to get it tested continuously. This patch attempts to solve the chicken-egg problem. It introduces a simple override for unstable tests: list them in file `utils/windows-llvm-lit-test-overrides.txt` and SwiftCI will skip/xfail them.
This approach has a number of benefits:
* overrides don't need to be in sync with https://github.com/swiftlang/llvm-project
* overrides are tracked in one place and are not spread across the LLDB test suite
* overrides are swiftlang-specific, which clearly states the differences to upstream LLVM
* we can enable continuous testing (and get reports for new failures) without fixing the world first
Once the remaining subset of tests passes reliably, we can iterate to enable the others and increase coverage. This change implements the infrastructure. There is a separate PR to enable tests in CI, which can be reverted with fewer side-effects.
Add support to `Build-CMakeProject` to use the GNU driver on Windows.
This is preparatory work to get the experimental runtime build working
(and subsequently enable a static SDK for Windows). It also opens the
possibility to explore the performance gap between MSVC and clang.
This hoists the cleaning to prior to building the toolchain. This is
particularly important as changes in the module format may cause the
compiler to crash. Due to the use of Swift in the Swift compiler, we
load modules early and a previous run may have left over modules from
the last run, which would result in the module attempting to be loaded.
This cleans out the extra modules before the toolchain build avoiding
that.
This patch enables the new runtime build in macOS smoke testing in CI.
This is only ensuring that the default configuration builds and does not
enable anything fancy at this time.
The problem with `is_escaping_closure` was that it didn't consume its operand and therefore reference count checks were unreliable.
For example, copy-propagation could break it.
As this instruction was always used together with an immediately following `destroy_value` of the closure, it makes sense to combine both into a `destroy_not_escaped_closure`.
It
1. checks the reference count and returns true if it is 1
2. consumes and destroys the operand
Somehow the new build system is affecting the old build system in such a
way that it's not producing the Swift Concurrency runtime for smoke
testing, resulting in test failures due to the missing library.
```
/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/llvm-macosx-x86_64/bin/llvm-nm: error: /Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/swift-macosx-x86_64/lib/swift/macosx/x86_64/libswift_Concurrency.dylib: No such file or directory
```
This isn't even a directory that is affected by the new build, but
disabling to try to bring things back up.
Clear out the android builds as well as any leftovers from a previous
test run which would possibly break the build in the case that the
compiler was updated.
Build System as static as it has been internalised into SPM and no
longer needs to be shared across multiple targets. This reduces the
number of distributed files and helps reduce the binary size (~56KiB).
SwiftSystem is only used in a single location in SPM, allowing us to
collapse the file into the single site. This reduces the overall
toolchain size by ~56K. It also removes the need to ship the extra DLL.
`JSONEncoder` by default will escape slashes, which results in a string
that isn't technically valid Base64. Since that behaviour is optional,
turn it off, and at the same time tell it to output in lexical key
order, which makes the test slightly simpler (no `CHECK-DAG` needed).
Also fixed a typo in `test_swift.py`
rdar://124913332
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
