If the Swift error wrapped in a _SwiftNativeNSError box conforms to
Hashable, the box now uses the Swift's conformance to Hashable.
Part of rdar://problem/27574348.
This partially reverts commit
47f01ee98d. In other words, I'm bring
back the changes to the Swift runtime that should eliminate the data
race in swift_bridgeErrorToNSError, but leaving the actual test
disabled while we do more investigation.
SILGen already attempts to extract an embedded NSError when
type-erasing to an Error existential; make the runtime do the same
thing dynamically.
Huge thanks to Joe Groff who noticed that I missed this path.
Huge thanks to John for noting that 'consume' didn't provide the
guarantees we wanted, and to Michael G. for getting a TSan build up
and running to identify/verify this race.
It's possible that this is overlay strict, and that we only need to
look at the domain to ensure that the code and userInfo are
visible. However, TSan seems to prefix the form in this patch, so
we'll be more conservative for now.
Fixes rdar://problem/27541751.
Imported Cocoa error types are represented by structs wrapping an
NSError. The conversion from these structs to Error would end up
boxing the structs in _SwiftNativeNSError, losing identity and leading
to a wrapping loop.
Instead, extract the embedded NSError if there is one. In the Swift
runtime, do this as part of the dynamic cast to NSError, using a (new,
defaulted) requirement in the Error type so we can avoid an extra
runtime lookup of the protocol. In SILGEn, do this by looking for the
_BridgedStoredNSError protocol conformance when erasing to an Error
type. Fixes SR-1562 / rdar://problem/26370984.
All generic bridgeable types can bridge for all their instantiations now. Removing this ferrets out some now-unnecessary traps that check for unbridgeable parameter types.
- Any is made into a keyword which is always resolved into a TypeExpr,
allowing the removal of the type system code to find TheAnyType before
an unconstrained lookup.
- Types called `Any` can be declared, they are looked up as any other
identifier is
- Renaming/redefining behaviour of source loc methods on
ProtocolCompositionTypeRepr. Added a createEmptyComposition static
method too.
- Code highlighting treats Any as a type
- simplifyTypeExpr also does not rely on source to get operator name.
- Any is now handled properly in canParseType() which was causing
generic param lists containing ‘Any’ to fail
- The import objc id as Any work has been relying on getting a decl for
the Any type. I fix up the clang importer to use Context.TheAnyType
(instead of getAnyDecl()->getDeclaredType()). When importing the id
typedef, we create a typealias to Any and declare it unavaliable.
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
If there's no better mapping for a Swift value into an Objective-C object for bridging purposes, we can fall back to boxing the value in a class. This class doesn't have any public interface beyond being `NSObject`-conforming in Objective-C, but is recognized by the Swift runtime so that it can be dynamically cast back to the boxed type.
Provides a new fallback for Process arguments for those instances where we do
not own main (e.g. Frameworks, Objective-C owns main.m or main.c, etc.). This
includes a number of platform-specific specializations of argument grabbing
logic and a new thread-safe interface to Process.unsafeArgv.
main() | _NSGetArgc/_NSGetArgv | /proc/self/cmdline | __argc/__argv
--------|--------------------------|------------------------|---------------
Scripts | OS X, iOS, tvOS, watchOS | Linux, FreeBSD, Cygwin | Windows
For interpreted Swift where we must filter out the arguments we now do so by
loading the standard library and calling into new SPI to override the arguments
that would have been grabbed by the runtime. This implementation completely
subsumes the use of the entry point '_stdlib_didEnterMain' and it will be
removed in a future commit.
An error type can conform to one or more of these new protocols to
customize its behavior and representation. From an implementation
standpoint, the protocol conformances are used to fill in the
user-info dictionary in NSError to interoperate with the Cocoa
error-handling system.
There are a few outstanding problems with this implementation,
although it is fully functional:
* Population of the userInfo dictionary is currently eager; we
should use user info providers on platforms where they are
available.
* At present, the Swift dynamic casting machinery is unable to unbox a
_SwiftNativeNSError when trying to cast from it to (e.g.) an
existential, which makes it impossible to retrieve the
RecoverableError from the NSError. Instead, just capture the original
error---hey, they're supposed to be value types anyway!---and use that
to implement the entry points for the informal
NSErrorRecoveryAttempting protocol.
This is part (1) of the proposal solution.
under the lock.
Unfortunately, unit-testing this is gratuitously difficult
because of C++ problems. (Fixed in C++17, apparently.) Will
be tested by a future patch which creates a nested foreign
type.
When the standard library is built dynamically on COFF targets, the public
interfaces must be decorated in order to generate a proper DLL which can be
confused by the dependent libraries. When the exported interface is used, it
must be indirectly addressed. This can be done manually in code or the MS
extension of `__declspec(dllimport)` may be used to indicate to the compiler
that this symbol be addressed indirectly. This permits building more pieces of
the standard library dynamically on Windows.
There were places were RelativeDirectPointers were copied using bitwise copies, which is semantically wrong. This patch makes sure it cannot happen anymore.
Always include all the sources as we cannot include object libraries to be
subsumed. This allows us to conditionally build the swift runtime for foreign
hosts simultaneously (e.g. cross compile for Linux and Windows simultaneously).
Build the section_magic libraries for all the ELFish SDKs that have been
configured. This allows us to build for SDKs which dont match the object format
at the same time (e.g. Linux and Windows).
