With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
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
* 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
Some people are reporting problems with the features file being missing
during testing. Try executing the same process that will regenerate the
files when dependencies change during CMake generation, so the file is
there after the project is configured.
(Maybe)
Fixes#77642
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.
The build script will build these pieces because they are wired to the
tools and compiler components, but when using `ninja` or `cmake`
directly to clean the build, and then later `check-swift-validation` and
other test targets, it would not rebuild those targets, failing many of
the macros/plugins tests.
This was added by #71839 as part of a fix for the
`TypeRoundTrip/round-trip.swift` test, but it isn't necessary and
it's breaking nightly builds.
rdar://128000843
`TypeRoundTrip/round-trip.swift` tries to link with `libswiftRemoteInspection`,
but that library isn't in the default link path, so we need to add a `-L`
option to the command line in the test.
Also, we should check that `SWIFT_BUILD_REMOTE_MIRROR` is enabled and
disable the test if not, because otherwise `libswiftRemoteInspection` won't
have been built.
rdar://123503470
Declare a new `LINUX_STATIC` SDK and configure it.
Add options to set the build architectures for the `LINUX` and
`LINUX_STATIC` SDKs, similar to what we have for Darwin, because
we'll be cross-compiling.
Also add an option to point the build system at the sources for
the musl C library, which we're using for `LINUX_STATIC`.
rdar://123503470
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
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.
PR #72293 added the synchronization module to embedded, and it was added
as dependency of `ALL`, but not of the `-test-depends` targets. If one
is using the `-test-depends` targets, the synchronization library for
embedded will not be build, and the test will fail.
This is a follow up to #72329. I had a partial build to test that, and
I did not notice this was also missing.
The swift-scan-test is exclusively used from the tests, but it was not
added to the `*-test-depends` targets, so trying to prepare the test
dependencies will not had build it, and test failures will happen.
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`.
When not building `all`, like the `build-script` does in CI, the tests
did not have a dependency on `embedded-stdlib`, and those tests will
fail to pass if one was using CMake/Ninja to execute the tests after
something like `ninja clean`.
The dependency is added if the embedded stdlib is being built.
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.
For platforms that support only static stdlib (i.e. `if(NOT SWIFT_BUILD_DYNAMIC_STDLIB AND SWIFT_BUILD_STATIC_STDLIB)` we should set `test_resource_dir` value correctly to use the `swift_static` subdirectory.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
zippered.
This also introduces a dependency on new testing tool
llvm-tapi-diff. This allows for a structural difference check on tbd
files.
resolves: rdar://107368040
Teach swift dependency scanner to use CAS to capture the full dependencies for a build and construct build commands with immutable inputs from CAS.
This allows swift compilation caching using CAS.
