This inefficient call took up 8-9% of the compile time of Global ARC Opts when
compiling a release no-assert stdlib with a release compiler with assertions.
NFC.
<rdar://problem/22244924>
Swift SVN r31167
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
In iOS 9 and OS X 10.11 the old GameKit was effectively renamed GameCenter, while
the new GameKit is a sort of umbrella framework like Cocoa. We need to support
backwards deployment, though, so the GameCenter overlay links to GameKit.framework.
(This is essentially the same solution implemented for CoreImage moving out of
QuartzCore in r28449)
rdar://problem/21340738
Swift SVN r30322
CNErrorDomain is lacking proper availability annotations, and
explicitly linking with -weak_framework is not working reliably. For
now, just remove the overlay to solve rdar://problem/21030937. We'll
bring it back when rdar://problem/21032649 makes it into all of the
builds we care about.
Swift SVN r29003
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
Introduce a number of small overlays to bridge the NSError domains for
a number of frameworks into existing imported enums. This batch only
covers cases where there is an existing NS_ENUM describing the codes
for the domain, so we need only extend that enum to provide the
appropriate _BridgedNSError conformance.
This is the bulk of rdar://problem/20536610.
Swift SVN r28585
On OS X 10.10 and earlier, CoreImage is a sub-framework of QuartzCore.
Users of CoreImage use "import QuartzCore" and link against QuartzCore.
On OS X 10.11 (and in the OS X 10.11 SDK), CoreImage is a top-level
framework. Users of CoreImage use "import CoreImage" and would link against
CoreImage. Of course, QuartzCore continues to re-export CoreImage's API.
When backwards-deploying, we need to continue linking against QuartzCore,
but still need to bring in the overlay if you import CoreImage. That's
what this patch does.
rdar://problem/20196610
Swift SVN r28449
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
