Functions like withUnsafeBufferPointer are, by themselves, safe to
call. It's only the operations on the unsafe pointers passed into the
closure that are the safety issue.
This was the intent spelled out in SE-0458 but was not fully realized
in the library.
Fixes rdar://174519372.
At the same time, drop that dependency in the new build system, so that
we don't add an additional linkage for Darwin platforms compared to what
we are doing in the current build system.
Addresses rdar://158314427
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
This applies more annotations in the `INTERNAL_CHECKS_ENABLED` disabled
paths, Windows, 32-bit, and non-ObjC paths. Interestingly enough, there
are a couple of compiler intrinsics which are also uncovered.
The SDK overlays have been provided in the Apple SDKs for many years, and the interface and implementation has diverged in more recent years such that trying to build the Swift version no longer works. Remove all of the dead code.
rdar://151889154
... that would import that as a result of importing Darwin from the SDK.
Amend my previous change to Differentiation and Distributed in this
sense.
Addresses rdar://150400049
Function types aren't always trivially copyable, e.g. with address-discriminated signed pointers on ARM64e. Introduce a function_cast helper and use that instead.
We need this so that older compilers can handle the .swiftinterface
files we generate. It's unnecessary for newer compilers and can be
removed later.
Fixes rdar://148529962.
This silences some of the newer warnings about the casting of function
pointers which is technically not permitted by the standard (function
and data pointers are not guaranteed to be the same).
These modules import Darwin which is not in ossa. -enable-ossa-modules
results in a one-time recompilation of dependencies when they are not in ossa.
This is not compatible with Explicit Build Modules when the original invocation
did not have -enable-ossa-modules.
Everywhere there's a `SWIFT_MODULE_DEPENDS_LINUX Glibc`, there should be
a corresponding `SWIFT_MODULE_DEPENDS_LINUX_STATIC Musl`.
This usually won't bite us, depending on build order and parallelism, but
I hit one of these yesterday so went looking to see if there were any
others.
rdar://136208589
https://github.com/swiftlang/swift/pull/72612 can be reverted because it is no
longer necessary for the interface of the stdlib to be compatible with
compilers without `$TypedThrows` support.
And it is handled compatibly because all existing implementations must
have already implemented it before -- it was an ad-hoc requirement
before Swift 6.0, and now it has become a real requirement - the same as
all the other ad-hoc requirements relying on the Serialization
Requirement
I had to change the APIs to always be always emit into client instead of back
deployable since silgen_name seems to interfere with @backDeployment. So I
switched the implementation so that it instead uses an always emit into client
thunk with the in source function name and a usableFromInline function that has
the silgen_name. This ensures that we still appropriately export the same symbol
as we did before, so it is ABI stable.
This was approved as part of se-0414.
rdar://122030520
Konrad `ktoso` Malawski
Doug Gregor
Allan Shortlidge
Alex Martini
Erik Eckstein
Eric Miotto
Gabor Horvath
Saleem Abdulrasool
Ian Anderson
Eric Miotto
Mike Ash
Meghana Gupta
Konrad `ktoso` Malawski
Konrad `ktoso` Malawski
Alastair Houghton
Alex Hoppen
Mykola Pokhylets
Alexander Cyon
Alex Lorenz
Holly Borla
Pavel Yaskevich
Michael Gottesman