The Clang importer introduces a number of synthesized conformances for
imported enums (normal, NS_ENUMS, or NS_OPTIONS-based all have the
same issue) that aren't used in most translation units. Rather than go
through the effort of fully checking these conformances and generating
SIL for them always, rely on semantic analysis to force them to be
fully checked when the conformance is required. This cuts down on the
amount of work we need to do for imported enumeration types
considerably. For a simple program consisting of only:
import Foundation
var str = NSString()
My not-entirely-scientific measurements show that:
* Time to parse + type-check is reduced by 34%
* Time to generate SIL is reduced by 50%
* Time to generate IR is reduced by 47%
* SIL output size is reduced by 66%
Fixes rdar://problem/20047340.
Swift SVN r27946
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
With runtime conformance lookup, it isn't possible without more complex analysis to determine whether a witness table is needed at runtime. In particular, in whole-module mode, it looked like no protocol conformances in the test/Interpreter/protocol_lookup.swift test were used, causing all of the tests to fail in -i mode. Erik's been working on SIL-level dead witness elimination which will hopefully offset the compile time hit here.
Swift SVN r23067
therefore allowed to come without debug info.
This fixes a test suite failure with unoptimized stdlibs.
Thanks Erik for helping debug this.
Swift SVN r22266
functions, and make those functions memoize the result.
This memoization can be both threadsafe and extremely
fast because of the memory ordering rules of the platforms
we're targeting: x86 is very permissive, and ARM has a
very convenient address-dependence rule which happens to
exactly match the semantics we need.
Swift SVN r20381
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
The real Swift overlays for ObjectiveC and Foundation are fine for these
tests. Mainly we just want to test that code building off of Foundation
works at all.
Swift SVN r7373
