This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
Add @PointerBounds macro
@PointerBounds is a macro intended to be applied by ClangImporter when
importing functions with pointer parameters from C headers. By
leveraging C attributes we can get insight into bounds, esapability, and
(eventually) lifetimes of pointers, allowing us to map them to safe(r)
and more ergonomic types than UnsafePointer.
This initial macro implementation supports CountedBy and Sizedby, but
not yet EndedBy. It can generate function overloads with and without an
explicit count parameter, as well as with UnsafeBufferPointer or Span
(if marked nonescaping), and any of their combinations. It supports
nullable/optional pointers, and both mutable and immutable pointers.
It supports arbitrary count expressions. These are passed to the macro
as a string literal since any parameters referred to in the count
expression will not have been declared yet when parsing the macro.
It does not support indirect pointers or inout parameters. It supports
functions with return values, but returned pointers can not be bounds
checked yet.
Bounds checked pointers must be of type Unsafe[Mutable]Pointer[?]<T>
or Unsafe[Mutable]RawPointer[?]. Count expressions must conform to
the BinaryInteger protocol, and have an initializer with signature
"init(exactly: Int) -> T?" (or be of type Int).
rdar://137628612
---------
Co-authored-by: Doug Gregor <dgregor@apple.com>
Take the `Features.def` file used in other parts of the code and create
a file that can be used from the LLVM Lit configuration files to add new
available features that can be checked from the tests with `REQUIRES`
and others.
The file `lit.swift-features.cfg.inc` is preprocessed by Clang and
generates a file with Python syntax that can be loaded from both
`lit.site.cfg.in` files. The preprocessing output is copied into the
different test directories in the build directory, and added it is added
as a dependency of them, so it will be generate when the test run or
when `Features.def` changes.
`EXPERIMENTAL_FEATURES` are only enabled if they are available in
production or the compiler is being built with assertions, while
`UPCOMING_FEATURES` and the rest of the `LANGUAGE_FEATURES` are always
available.
When doing an unified build (Swift being an external project of LLVM),
the Swift build is at `<llvm build dir>/tools/swift`, and that is the
value of `swift_obj_root`. However many products are actually placed in
`<llvm build dir>`, like `bin/`, `include/` and things like
`lib/swift/...` and others.
A couple of macros tests check the error messages printed by the
compiler against `swift_obj_root` (by the replacement done in
`PathSanitizingFileCheck` of `BUILD_DIR`) when it should have been
checking them against the top-level build directory, which will work in
both unified and non-unified builds (like `build-script` builds).
Now that SwiftCompilerSources are always enabled, `swift_in_compiler` is not needed anymore.
Set this feature unconditionally for tests which still include `REQUIRES: swift_in_compiler`.
Now that the compilation model of noncopyable types is enabled everywhere,
and one can enable the feature for specific modules, we no longer need a
separate build-script/CMake option to enable it globally. Remove it all.
We don't currently support building resilient relative protocol witness tables.
One might want to build with relative witness tables but not need
resilient protocols. Allow for that scenario.
Add a test configuration to test library-evolution + fragile resilient
protocols + relative protocol witness tables.
With this build-script has a flag --enable-experimental-nonescpable-types=1
to enable this feature in stdlib.
Also we can now add // REQUIRES: nonescapable_types to tests which run only when
the compiler is built with this feature turned on.
This patch introduces `--enable-experimental-noncopyable-generics` for
the build script. It replaces
`--swift-stdlib-experimental-noncopyable-generics`
The old build option only enables the feature when building the
stdlib, but if we've built the stdlib with NoncopyableGenerics, the
compiler should be hardwired to have that feature enabled, too.
This patch also introduces the `noncopyable_generics` lit parameter, so
that tests assuming the system was built with the feature can live
in-tree and be tested, if they specify `REQUIRES: noncopyable_generics`.
This library served its purpose and has overstayed its welcome.
The library shipped in Xcode can't change again from the state it was
in, so changes to the sources here will not affect that library, which
is confusing. The library does not currently build due to changes in the
runtime headers, so it does not give meaningful signal to anything
anymore. If you need to test things in a backdeploy concurrency
environment, use the copy from the toolchain in Xcode as that will give
you a far clearer picture of what the code will actually be running with
than the state of the sources here did.
The main change here is in IRGen which needs to be able to emit constant enum values.
Use `emitValueInjection` to create the enum constant.
Usually this method creates code in the current function.
But if all arguments to the enum are constant, the builder never has to emit an instruction.
Instead it can constant fold everything and just returns the final constant.
Also, create statically initialized let-globals as constant global (`constant` instead of `global`).
In some Linux setups, one might need to provide extra arguments to setup
the environment for invocations done during the tests. The Swift
frontend and driver already had a mechanism to provide those arguments
in the shape of `SWIFT_FRONTEND_TEST_OPTIONS` and
`SWIFT_DRIVER_TEST_OPTIONS`. `swift-ide-test` was sadly missing the same
feature, which meant that many tests might fail or tests against the
incorrect environment.
The changes implement the `SWIFT_IDE_TEST_TEST_OPTIONS` mechanism to
cover that gap.
The feature "reflection" was already used in the tests (enabled with
SWIFT_ENABLE_REFLECTION). The new feature tests were triggered even if
the experimental feature was not enabled in people builds.
Change the spelling to "reflection_runtime" to not clash with the
existing feature. Change all the tests I found added lately that has the
existing spelling.
* Move Runtime into _Runtime
Fix more _Runtime names
* Add availability to all API
* Build _Runtime and Reflection modules
* Use threading's mutex for all platforms
add stdlib include
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
Any substring of `target_triple` is allowed as a feature (when used in
REQUIRES/UNSUPPORTED/XFAIL) in `lit.py`. This is what allows eg. `XFAIL:
linux` even though `linux` isn't listed as an available feature.
`TARGET_TRIPLE` was renamed to `LLVM_TARGET_TRIPLE` upstream, so rename
it here as well. Going forward we should remove `target_triple` entirely
and use our `OS=...` features instead.
* add an option to add freestanding to the Darwin platform, so that
to get expected compile behaviours (e.g. setting the install name)
* rework testing configuration to relax assumptions about freestanding
* add a preset to test such configuration (at least for PR testing)
Addresses rdar://85465396
These modules are part of the experimental declarative string processing feature. If accepted to the Standard Library, _StringProcessing will be available via implicit import just like _Concurrency, though _MatchingEngine will still be hidden as an implementation detail.
`_MatchingEngine` will contain the general-purpose pattern matching engine ISA, bytecode, and executor. `_StringProcessing` will contain regular expression and pattern matching APIs whose implementation depends on the matching engine..
Also consolidates frontend flag `-enable-experimental-regex` as `-enable-experimental-string-processing`.
Resolves rdar://85478647.
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
The logic in test/lit.site.cfg.in and validation-test/lit.site.cfg.in is
largely duplicated. This adds some of the missing features in order to
try to fix backdeployconcurrency testing. This should be more
fundamentally fixed to keep the different test configs in sync.
Since the NDK removes the platforms/ and sysroot/ directories in the latest NDK
22, switch to the unified sysroot in toolchains/llvm/ and take advantage of a
bunch of simplification that's now possible.
This causes build-script to use the conservative dependency information that I
committed. When one uses this option, it is assumed that one wants to also
install all built products.
Some notes:
1. I included an extra --install-all option so without --infer enabled
one can enable this sort of install everything that we want to
build behavior.
2. I added %cmake as a lit variable. I did this so I could specify in
my build-system unit tests that on Linux they should use the just
built cmake (if we built cmake due to an old cmake being on the
system). Otherwise, the build system unit tests took way too
long. These are meant to be dry-runs, so building this cmake again
is just wasteful and doesn't make sense.
3. I unified how we handle cmark, llvm, swift with the rest of the
build products by making them conditional on build_* variables, but
to preserve current behavior I made it so that they are just
enabled by default unlike things like
llbuild/swiftpm/foundation/etc. This was necessary since previously
we would just pass these flags to build-script-impl and
build-script didn't know about them. Now I taught build-script
about them so I can manipulate these skip-build-{cmark,llvm,swift}
and then just pass them down to build-script-impl if appropriate
rather than relying on build-script-impl to control if these are
built.
Once this lands, I think we are at a good enough place with
build-script until we get rid of build-script-impl in terms of high
value QoI that will imnprove productivity. Once build-script-impl is
destroyed, we can start paring back what build-script itself does.
Also remove some ancient logic to detect and ignore requests to use LLD.
If people want to explicitly use LLD, they probably have a reason and we
shouldn't second guess them.
Many places on the testing scripts for Android have the ARMv7
architecture hardcoded. Modify all those instances to support both ARMv7
and AArch64.
Besides the paths being modified depending on the architecture, the
script is also modified to adapt to NDK beyond r14, where the headers
are not under the SDK root, but under a unified sysroot. Two new include
paths are passed to the compiler invocations (one the general one, one
the architecture specific one).
In order to link correctly, the -tools-directory is passed to the Swift
compiler invocation. In order to use a modern linker, the selected
linker in the CMake script is written in the lit.site.cfg.in files. The
system will prefer lld, but will fallback to gold. Plain ld will not be
used, since it cannot link correctly the binaries.
There's a new CMake variable named SWIFT_ANDROID_${ARCH}_ICU_DATA that
should point to libicudataswift.so for each architecture. This part of
ICU is necessary while running the test in the host, so it needs to be
uploaded. Since it is normally side by side with other ICU products, the
linker was finding it for free.
* Revert "[strip -ST] Disable runtime stack trace dumping on Darwin when asserts are disabled."
This reverts commit 6bc28ff1c9.
* Bring back important fixes from the revert of 6bc28ff1c9.
* Change swift::swift_reportError to only print the backtrace in assert builds (swift::warning prints backtrace always).
This commit disables runtime stack trace dumping via dladdr on Darwin when
asserts are disabled.
This stack trace dumping was added as a way to improve the ability to debug the
compiler for compiler developers. This is all well and good but having such a
feature always enabled prevents us from reducing the size of the swift standard
library by eliminating the swift nlist.
rdar://31372220
