Dynamic replacements are currently written in extensions as
extension ExtendedType {
@_dynamicReplacement(for: replacedFun())
func replacement() { }
}
The runtime implementation allows an implementation in the future where
dynamic replacements are gather in a scope and can be dynamically
enabled and disabled.
For example:
dynamic_extension_scope CollectionOfReplacements {
extension ExtentedType {
func replacedFun() {}
}
extension ExtentedType2 {
func replacedFun() {}
}
}
CollectionOfReplacements.enable()
CollectionOfReplacements.disable()
At least test_rth.swift is checking the name of the executable
during the test, so renaming every executable to __executable in
Android will never work.
Also, during the rth tool execution, all the results from before
and after are pushed for every test. Since Android copies the
passed files without relative paths, the library files will
overwrite each other, making the test fail.
Depends on #19949 (more or less)
- Update --reset-to-remote to support tags.
- Add optional platform entry to a repository. This allows specifying
which platforms a repo should be checked out on.
- Uses version 61.1 from ICU Github unicode-org/icu repository.
- Updates mixin_linux_installation to add libicu option.
- Use -j when building libicu.
- When buiding ICU, use --with-library-suffix=swift
This suffixes the ICU symbols with _swift.
The libaries are now named libicuucswift, libicui18nswift
and libicudataswift.
- Add the contents of uconfig.h.prepend into uconfig.h. This avoids
passing the renaming CFLAGS to swift and swift-corelibs-foundation.
Also resolves:
SR-5618: libicu compilation should happen in parallel respecting -j.
The key thing is that these skip all testing except for the integration testing
and thus are perfect for subproject buildbot testing.
The reason why I am doing this is I discovered that dispatch is not using
build-presets. This means that dispatch may not get updated properly (resulting
in integration test failures) when we add new package installation dependencies
(like llvm-cov, llvm-profdata) for the integration tests.
This is functionally the same as dispatch's build today except that we /will/
build lldb. That being said I think it makes sense to build the entire package
for dispatch so if we have any integration issues in between lldb and dispatch
we can test them.
SR-9080
Support for Android aarch64 in many parts of the build-script. Most of
the changes are reuse variables/parameters that already existed for
Android ARMv7. There is also a new parameter to specify the ICU
data library, which is used by #19503.
With this one can build either armv7 or aarch64, since building both
at the same time requires more changes like #19432 (and probably
more work to support two set of paths).
Some tests need more than just the executable to be pushed. For
example the resilience tests need the executable and the linked
library to be pushed. adb_test_runner.py only pushed the
executable.
The changes look into the arguments passed to the executable
and figure out which ones refer to files. Those files are pushed
to the device and transformed to refer to the path on the device
instead (the resilience test do not actually use the argument
values themselves, but maybe others do).
...i.e. an actual shell-like argument list, rather than a
semicolon-separated list (CMake's internal stringification mechanism
for lists). Apart from being a little easier to read, this also works
directly with the response file support in swiftc itself now (not
depending on utils/line-directive).
(It's still not /quite/ enough to expand on a command-line, though,
since that will escape the quotes. The 'sed' command can get around
that: $(sed "s/'//g" foo.txt).)
Update the commands to use the CMake based output directory locations instead of
the legacy staging location. This will allow us to stop copying the files for
compatibility.
When running tests in an Android device, the environment variables
were not passed to the device, which make some test fail, like
stdlib/HashingRandomization that test with and without the
environment variable SWIFT_DETERMINISTIC_HASHING.
The changes implement a process similar to what the iOS simulator
already seem to do: a variable prefix which is pick up by the
adb_test_runner.py and send to the device for the test.
Ubuntu 16.04 doesn't include LLD, and the included gold doesn't
link Android correctly.
Because of the change in e7ba154d59
the -B option was not passed during compiling, and the Ubuntu gold
was being used in the CI (the default value for
SWIFT_ENABLE_LLD_LINKER is ON, even if LLD is not present).
This change sets the value to OFF in the preset, so LLD will not
try to be used in CI. All other builds should be unchanged, so in
other developers setups the compiling machine LLD will try to be
used (which works on more recent Ubuntu versions).
Pass along the configuration through the exported target for the standard
library. Still pass the compiler by hand to allow building libdispatch against
just a build of the standard library.
