Deprecated the `PlaygroundQuickLook` enum and `CustomPlaygroundQuickLookable`
protocol. These are being targeted for removal in Swift 5, so we want to
unconditionally deprecate them now to encourage use of
`CustomPlaygroundDisplayConvertible` instead.
This commit includes deprecated the various `CustomPlaygroundQuickLookable`
conformances across the standard library and overlay libraries.
This initializer, which is the same on iOS, allows negative values and
values > 1.0 to support the extended sRGB color space.
Fixes rdar://problem/33500905.
These were supposed to help during the early days of Swift 3, when our
omission of needless words was being tempered by framework authors'
explicitly-specified names in API notes...but they were accidentally
not made public, and no one noticed. After checking with the AppKit
team, we decided to just drop them.
...to remove the temptation to put everything in one file with the same
name as the module. This doesn't do anything for overlays that /already/
have everything in one file with the same name as the module, except for
a few easy cases; we can unpack the rest later.
os/activity.h or os/log.h. Update cmake files again, hardcoding a Darwin
dependency. The script does not notice that Foundation depends on
CoreGraphics, so add that manually.
Also found that MapKit is supported on WATCHOS but we didn't have dependencies
for that.
Favor one line per supported SDK instead of catch-all dependency lines.
Distinguish from SDKs which have no dependencies vs SDKs which are
unsupported on a particular platform by printing `unsupported` to the
console and remove the line in the cmake file because it should
not exist anyway.
This full cleanup was not done before because of circularity detected by the
util, which has since been fixed.
Support directories with spaces.
Implements part of SE-0110. Single argument in closures will not be accepted if
there exists explicit type with a number of arguments that's not 1.
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
Note there's a second part of SE-0110 which could be considered additive,
which says one must add an extra pair of parens to specify a single arugment
type that is a tuple:
```swift
let g ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
This patch does not implement that part.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
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.
semantically unambiguous.
We didn't actually intend to change how programmers normally
constructed these types, but the change to the object literal
syntax accidentally caused these initializers to have very
natural-seeming signatures. These initializers also created
possible ambiguities with the actual initializers. Renaming
them to refer to their function as literal initializers is the
right thing to do.
Unfortunately, this provided to be somewhat annoying, as the
code was written to assume that the argument tuple following
e.g. #colorLiteral could be directly passed to the initializer.
We solve this by hacking on both ends of the constraint system:
during generation we form a conversion constraint to the
original, idealized parameter type, and during application we
rewrite the argument tuple type to use the actual labels.
This nicely limits the additional complexity to just the
parts dealing with object literals.
Note that we can't just implicitly rewrite the tuple expression
because that would break invariants tying the labels to physical
source ranges. We also don't want to just change the literal
syntax again and break compatibility with existing uses.
rdar://26148507
* Implement the majority of parsing support for SE-0039.
* Parse old object literals names using new syntax and provide FixIt.
For example, parse "#Image(imageLiteral:...)" and provide a FixIt to
change it to "#imageLiteral(resourceName:...)". Now we see something like:
test.swift:4:9: error: '#Image' has been renamed to '#imageLiteral
var y = #Image(imageLiteral: "image.jpg")
^~~~~~ ~~~~~~~~~~~~
#imageLiteral resourceName
Handling the old syntax, and providing a FixIt for that, will be handled in a separate
commit.
Needs tests. Will be provided in later commit once full parsing support is done.
* Add back pieces of syntax map for object literals.
* Add parsing support for old object literal syntax.
... and provide fixits to new syntax.
Full tests to come in later commit.
* Improve parsing of invalid object literals with old syntax.
* Do not include bracket in code completion results.
* Remove defunct code in SyntaxModel.
* Add tests for migration fixits.
* Add literals to code completion overload tests.
@akyrtzi told me this should be fine.
* Clean up response tests not to include full paths.
* Further adjust offsets.
* Mark initializer for _ColorLiteralConvertible in UIKit as @nonobjc.
* Put attribute in the correct place.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
This pull request broke the following tests on several build configurations
(eg --preset=buildbot,tools=RA,stdlib=DA)
1_stdlib/Reflection.swift
1_stdlib/ReflectionHashing.swift
1_stdlib/UnsafePointer.swift.gyb
This reverts commit c223a3bf06, reversing
changes made to 5c2bb09b09.
Changes:
- Reverted commit reverting original SR-88 commit
- Removed mirror children helper collections and related code
- Rewrote some tests to keep them working properly
- Wrote two more tests for the three pointer APIs to ensure no crashes if created using a value > Int64.max
This reverts commit 8917eb0e5a.
Jira: SR-88
Changes:
- Removed stdlib type conformances to _Reflectable
- Conformed stdlib types to CustomReflectable, CustomPlaygroundQuickLookable
- Rewrote dump() function to not use _reflect()
- CGRect, CGPoint, CGSize now conform to CustomDebugStringConvertible
- Rewrote unit tests for compatibility with new API
