Second pass at updates for SE-0086 feedback
<rdar://problem/26892977> Make sure NSOrderedSet keeps its NS
<rdar://problem/26880016> NSBundleResourceRequest should keep its NS
<rdar://problem/26892958> Make sure NSAttributedString keeps its NS
<rdar://problem/26653694> NSCoder.decodeTopLevelObjectForKey does not follow naming guidelines
<rdar://problem/27355801> Foundation should have a structural type for TextCheckingResult
<rdar://problem/26770611> NSExpression naming is a bit awkward in swift
<rdar://problem/26653451> NSCoder encodeDataObject is misleading
<rdar://problem/26653653> NSCoder decodeObjectOfClass is redundant
NSCocoaError was capturing only the code of a Cocoa error, making it
basically useless. Instead, capture the entire NSError, the code of
which is tracked by an nested, RawRepresentable type Code. Provide
typed accessors for the common keys in the Cocoa error domain, e.g.,
NSFilePathErrorKey, NSStringEncodingErrorKey, NSUnderlyingErrorKey,
and NSURLErrorKey, to make this type easier to use.
This is specifically an implementation of part (4) of the proposed
solution to SE-0112, which makes NSCocoaError more usable. It also
adds localizedDescription to ErrorProtocol.
However, it also introduces the infrastructure needed for importing
error enumeration types more smoothly, e.g., ErrorCodeProtocol
(underscored for now), the ~= operator for matching error codes, and
so on. In essence, NSCocoaError is the pattern that the importer will
follow.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
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.)
-import-underlying-module deliberately avoids autolinking against that module,
since normally it's used when building the Swift half of a single binary.
For the overlays, however, that's not what we want, so add the underlying
framework explicitly.
Swift SVN r29439
The Cocoa error domain is comprised on error codes from Foundation,
CoreData, and AppKit. Rather than try to collect all of the error
codes into a single enum in Foundation, use a struct that conforms to
ErrorType. Part of rdar://problem/20536610.
Swift SVN r28755
