When building on macOS without the standard library but building the
extra toolchain content, we would fail to configure due to the missing
include of the `AddSwiftStdlib`.
This is a purely code motion change. It moves the functions that are
specific to `SwiftSource.cmake` into `SwiftSource.cmake`. Target
functions are moved to `stdlib/cmake/modules/AddSwiftStdlib.cmake`.
The format specifier constructed by the os log implementation uses '*' for
width and precision, and passes those values to the os_log ABIs as additional
arguments of the message. (The precision/alignment arguments have the
type: count).
Update tests to handle this change.
This builtin (which lowers to raw SIL that doesn't use an actual builtin
instruction) allows us to access an unmanaged value at +0 with a language
guarantee rather than relying on the optimizer.
Previously, we did not do this directly since without OSSA, we were scared that
the frontend/optimizer would not be able to safely emit this code. Now that we
have ownership ssa, we are able to ensure that the frontend always copies the +0
value passed into the closure if the value +0 escapes from the closure (either
via a return, storing into memory, or by passing off as a +1 parameter to a
function).
rdar://59735604
This adds the RangeSet and DiscontiguousSlice types, as well as collection
operations for working with discontiguous ranges of elements. This also adds
a COWLoggingArray type to the test suite to verify that mutable collection
algorithms don't perform unexpected copy-on-write operations when mutating
slices mid-operation.
This reverts commit beb8ecd8cc. Add a
workaround for the dependency issue.
It is unclear why `sourcekitd` is getting added improperly as a
dependency on `lib/sourcekitd.framework/sourcekitd`. This workaround
adjusts the dependency such that we end up with a dependency on
`lib/sourcekitd.framework/Versions/A/sourcekitd` as an order-only
dependency. This should fix the compile issue. I am unable to
reproduce this issue with the `add_library` usage for adding a Swift
library. This allows us to cleave the host and target libraries, and so
the workaround is sufficient to make progress and the problem will be
resolved with the migration towards CMake for handling the dependencies.
The link dependency is not sufficient, because this code depends on the
sourcekitd header and module map, which are produced during the build
process. This started failing after edbe22b63c, where the dependency
on `sourcekitd-test` was removed. That dependency was itself wrong,
but it happened to be a good enough approximation that we never saw
issues.
getDescription takes its argument at +1, but the implementation was passing the value directly. This caused the contained error value to be destroyed.
rdar://problem/59512630
The ConformanceCandidate constructor would eagerly instantiate metadata for
all non-generic types in the conformance cache. This was not the intention
of the code though, because it can compare nominal type descriptors --
which are emitted statically -- for those types that have them, namely
everything except for foreign and Objective-C classes.
Change the order of two calls so that the lazy path has a chance to run.
This fixes a crash when type metadata uses weakly-linked symbols
which are not available, which can come up in backward deployment
scenarios.
Fixes <rdar://problem/59460603>.
This moves the swift-lang library out of the tools/SourceKit directory
and into the stdlib directory. As it stands, the library required that
the standard library and the SDK overlay was being built. This is
implicitly done when building the stdlib subdirectory. Furthermore, it
had an odd tie between the flags for Swift and SourceKit which now have
the logic separated. This clearly delineates the host and target
components in the repository.
* Further refinement of {Float,Double,Float80}.init(_:String)
After talking with @stephentyrone, I found some additional simplifications. No
functional change, just shorter/simpler.
This makes the generic inlineable part a small stub that delegates to the full
non-inlined version.
ABI compatibility:
* We support the same generic init() as before
* _swift_stdlib_strtoXYZ_clocale is still available to
support old inlined code
API addition:
* We now have a public specialized form of init?(_: Substring)
in addition to the generic init?<S:StringProtocol> form.
* Add @available marker to new API
* Support back-deployment to older OSes by inlining the full version
These objects can escape into ObjC without their class being realized first, which can cause a crash if the unrealized class gets passed into the ObjC runtime.
rdar://problem/59295395
