Commit Graph

16 Commits

Author SHA1 Message Date
David Smith
1efa946caf Remove stdlib and runtime dependencies on Foundation and CF 2019-09-12 18:03:14 -07:00
Arnold Schwaighofer
fe69a86929 Revert "Remove stdlib and runtime dependencies on Foundation and CF"
It is causing bots to fail.

* Revert "The __has_include(<os/system_version.h>) branch here wasn't quite right, we'll just use the dlsym one for now"

This reverts commit f824922456.

* Revert "Remove stdlib and runtime dependencies on Foundation and CF"

This reverts commit 3fe46e3f16.

rdar://54709269
2019-08-26 13:00:08 -07:00
David Smith
3fe46e3f16 Remove stdlib and runtime dependencies on Foundation and CF 2019-08-23 14:10:23 -07:00
Mike Ash
317451c8ee [Runtime][Stdlib][Overlays] Add comments to all the renamed classes explaining the rename and noting that the old name cannot be used due to conflicts.
rdar://problem/35768222
2018-09-20 12:07:30 -04:00
Mike Ash
798edb9d0e [Runtime][Stdlib][Overlays] Rename various Objective-C classes and methods that would conflict when loading old Swift libraries into a process alongside ABI-stable libraries.
rdar://problem/35768222
2018-09-13 16:55:10 -04:00
Azoy
b8fc8b333c Remove _interface 2018-07-29 10:41:22 -04:00
Greg Parker
dd38ace506 [runtime] Fix more const cast warnings. (#11725)
* [runtime] Fix more const cast warnings.
2017-09-05 13:13:01 -07:00
Argyrios Kyrtzidis
9f62e5584f Fix -Wformat-pedantic warning. 2017-03-02 21:58:05 -08:00
Hugh Bellamy
05a50fd978 Remove extern "C" from uses of SWIFT_RUNTIME_STDLIB_INTERFACE 2017-01-22 18:32:17 +00:00
practicalswift
6d1ae2a39c [gardening] 2016 → 2017 2017-01-06 16:41:22 +01:00
Saleem Abdulrasool
c67a33fbc7 build: remove TARGET_SDKS from the runtime
The runtime and stubs are built for ALL targets, not specific ones.  This allows
us to configure when cross-compiling to Windows again.  Collapse the dual
addition of the swiftRuntime into a single build.  This unifies the runtime
build for the apple and non-Apple SDKs.  The difference here was the ObjC
interop sources.  In order to deal with that unification add a CPP macro to
indicate whether the interop sources should be included or not.
2016-12-03 17:02:44 -08:00
practicalswift
797b80765f [gardening] Use the correct base URL (https://swift.org) in references to the Swift website
Remove all references to the old non-TLS enabled base URL (http://swift.org)
2016-11-20 17:36:03 +01:00
practicalswift
f44686d825 [gardening] Fix trailing whitespace in *.cfg.in, *.html, *.mm and *.sil files 2016-10-29 14:06:43 +02:00
Joe Groff
1a52e3f2c2 SR-0140: Bridge Optionals to nonnull ObjC objects by bridging their payload, or using a sentinel.
id-as-Any lets you pass Optional to an ObjC API that takes `nonnull id`, and also lets you bridge containers of `Optional` to `NSArray` etc. When this occurs, we can unwrap the value and bridge it so that inhabited optionals still pass into ObjC in the expected way, but we need something to represent `none` other than the `nil` pointer. Cocoa provides `NSNull` as the canonical "null for containers" object, which is the least bad of many possible answers. If we happen to have the rare nested optional `T??`, there is no precedented analog for these in Cocoa, so just generate a unique sentinel object to preserve the `nil`-ness depth so we at least don't lose information round-tripping across the ObjC-Swift bridge.

Making Optional conform to _ObjectiveCBridgeable is more or less enough to make this all work, though there are a few additional edge case things that need to be fixed up. We don't want to accept `AnyObject??` as an @objc-compatible type, so special-case Optional in `getForeignRepresentable`.

Implements SR-0140 (rdar://problem/27905315).
2016-09-20 13:04:09 -07:00
Greg Parker
cd9a8afd5d Revert "SR-0140: Bridge Optionals to nonnull ObjC objects by bridging their payload, or using a sentinel." (#4820) 2016-09-15 18:18:07 -07:00
Joe Groff
cfa9cd9a08 SR-0140: Bridge Optionals to nonnull ObjC objects by bridging their payload, or using a sentinel.
id-as-Any lets you pass Optional to an ObjC API that takes `nonnull id`, and also lets you bridge containers of `Optional` to `NSArray` etc. When this occurs, we can unwrap the value and bridge it so that inhabited optionals still pass into ObjC in the expected way, but we need something to represent `none` other than the `nil` pointer. Cocoa provides `NSNull` as the canonical "null for containers" object, which is the least bad of many possible answers. If we happen to have the rare nested optional `T??`, there is no precedented analog for these in Cocoa, so just generate a unique sentinel object to preserve the `nil`-ness depth so we at least don't lose information round-tripping across the ObjC-Swift bridge.

Making Optional conform to _ObjectiveCBridgeable is more or less enough to make this all work, though there are a few additional edge case things that need to be fixed up. We don't want to accept `AnyObject??` as an @objc-compatible type, so special-case Optional in `getForeignRepresentable`.

Implements SR-0140 (rdar://problem/27905315).
2016-09-14 15:50:13 -07:00