Karoly removed the last use of _convertStringToNSString in f2a96496a;
the replacement is referenced by the runtime but not by the compiler.
Doug had removed all the others from the stdlib in d92ae7707.
rdar://problem/35230338
* [runtime] Clean up symbols in error machinery.
* [runtime] Clean up symbols in Foundation overlay.
* [runtime] Clean up symbols in collections and hashing.
* [runtime] Remove symbol controls from the Linux definition of swift_allocError.
* [tests] Add more stub functions for tests that link directly to the runtime.
This lets us eliminate the _getObjectiveCType() value witness, which
was working around the lack of proper type witness metadata in witness
tables. Boilerplate -= 1.
This reverts commit 052d2d0a69.
The only actual issue with the original change was a missing change to
the UIApplicationMain SILGen test, which needs to build SILGen
overlays to execute properly; -enable-source-import doesn't suffice.
Introduce a new entrypoint to _ObjectiveCBridgeable,
_unconditionallyBridgeFromObjectiveC, which handles unconditional
bridging from an optional Objective-C object (e.g., an NSString) to
its bridged Swift type. Use it in SILGen to perform NSString -> String
bridging rather than the custom entry point.
Another small step toward generalized bridging.
Provide a general mechanism for bridging from a Swift value type to
its corresponding Objective-C class type through the
_bridgeToObjectiveC witness of the appropriate _ObjectiveCBridgeable
protocol conformance. Only enable this new code for bridging String ->
NSString and work through the issues that crop up.
We cannot actually *delete* the _convertStringtoNSString entrypoint
yet, because there is some code that is depending on it indirectly;
I'll address that separately as part of the continued generalization
of the _ObjectiveCBridgeable mechanism.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
SILFunctionType of the method instead of its formal type.
Gives more accurate information to the @encoding, makes
foreign error conventions work implicitly, and allows
IRGen's Swift-to-Clang to avoid duplicating arbitrary
amounts of the bridging logic from SILGen.
Some finagling was required in order to avoid calling
getConstantFunctionType from within other kinds of
lowering, which might have re-entered a generic context.
Also required fixing a bug with the type lowering of
optional DynamicSelfTypes where we would end up with
a substituted type in the lowered type.
Also, for some reason, our @encoding for -dealloc
methods was pretending that there was a formal parameter.
There didn't seem to be any justification for this,
and it's not like Clang does that. Fixed.
This commit reapplies r29266 with a conservative build fix
that disables ObjC property descriptors for @objc properties
that lack a getter. That should only be possible in SIL
files, because @objc should force accessors to be synthesized.
Arguably, Sema shouldn't be marking things implicitly @objc
in SIL files, but I'll leave that decision open for now.
Swift SVN r29272
SILFunctionType of the method instead of its formal type.
Gives more accurate information to the @encoding, makes
foreign error conventions work implicitly, and allows
IRGen's Swift-to-Clang to avoid duplicating arbitrary
amounts of the bridging logic from SILGen.
Some finagling was required in order to avoid calling
getConstantFunctionType from within other kinds of
lowering, which might have re-entered a generic context.
Also required fixing a bug with the type lowering of
optional DynamicSelfTypes where we would end up with
a substituted type in the lowered type.
Also, for some reason, our @encoding for -dealloc
methods was pretending that there was a formal parameter.
There didn't seem to be any justification for this,
and it's not like Clang does that. Fixed.
Swift SVN r29266
When used in @objc protocol requirements, properties, or blocks, frameworks like JSCore expect the extended type encodings to accurately reflect the class of the parameters and returns. Fixes rdar://problem/19519390.
Swift SVN r28582
The internal details of ErrorType are still being designed.
They should be underscored in the meantime to
indicate they are still evolving.
Implements rdar://problem/20927102.
Swift SVN r28500
The string version of r26479. There's a lot of backstory and justification
there, so just read that commit message again. The one addition for String
is that global NSString constants are loaded as String as well, so that
also has to go through the bridging code even though there's no function
call involved.
Finishes rdar://problem/19734621.
Swift SVN r26510
...and similar for NSDictionary and NSSet.
For APIs that don't have a reason to distinguish "empty" and "absent" cases,
we encourage standardizing on "empty" and marking the result as non-optional
(or in Objective-C, __nonnull). However, there are system APIs whose
implementations currently do return nil rather than an empty collection
instance. In these cases, we recommend /changing/ the API to return the
appropriate "empty" value instead.
However, this can cause problems for backwards-deployment: while the API is
truly non-optional on system vN, a program may encounter a nil return value
if run on system vN-1. Objective-C can generally deal with this (especially
if the only thing you do is ask for the count or try to iterate over the
collection) but Swift can't. Therefore, we've decided to "play nice" and
accept nil return values for the collection types (NSArray, NSDictionary,
and NSSet) and implicitly treat them as "empty" values if they are the
result of an imported function or method.
Note that the current implementation has a hole regarding subscript getters,
since we still make an AST-level thunk for these in the Clang importer.
We can probably get rid of those these days, but I didn't want to touch
them at this point. It seems unlikely that there will be a subscript that
(a) is for a collection type, and (b) mistakenly returned nil in the past
rather than an empty collection.
There's another hole where an ObjC client calls one of these mistakenly-nil-
returning methods and then immediately hands the result off by calling a
Swift method. However, we have to draw the line somewhere.
(We're actually going to do this for strings as well; coming soon.)
rdar://problem/19734621
Swift SVN r26479
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
