This change includes a number of simplifications that allow us to
eliminate the type checker hack that specifically tries
AssertString. Doing so provides a 25% speedup in the
test/stdlib/ArrayNew.swift test (which is type-checker bound).
The specific simplifications here:
- User-level
assert/precondition/preconditionalFailure/assertionFailer/fatalError
always take an autoclosure producing a String, eliminating the need
for the StaticString/AssertString dance.
- Standard-library internal _precondition/_sanityCheck/etc. always
take a StaticString. When we want to improve the diagnostics in the
standard library, we can provide a separate overload or
differently-named function.
- Remove AssertString, AssertStringType, StaticStringType, which are
no longer used or needed
- Remove the AssertString hack from the compiler
- Remove the "BooleanType" overloads of these functions, because
their usefuless left when we stopped making optional types conform
to BooleanType (sorry, should have been a separate patch).
Swift SVN r22139
When the solver has attempted to produce a solution using the default
literal type tha has failed, dont' try every type that conforms to
that literal type. Instead, try the bridged class type (which deals
with the common AnyObject case) or one of two other options:
- For integer literals, try the default floating point type (Double)
- For string literals, try the standard library's AssertString (this
is a temporary hack)
This limits exponential blow-up in cases where the literal's type
cannot be determined from context. Addresses rdar://problem/18307267.
Swift SVN r22131
Trying a collection literal early often means that we can determine
the element type from context, which saves us the work of trying to
guess at the element type firsthand.
Doing this seems to help some cases significantly:
- test/stdlib/ArrayNew.swift got about 20% faster in a release build
- I had to drop the threshold for the "expression too complex" test
case by 20x to still trigger the issue.
Swift SVN r22097
A tuple of lvalues behaves semantically like an lvalue, so for consistency with scalar lvalues, we should diagnose ignored lvalue tuples in offline code, or coerce them to rvalues in REPL or playground contexts, because these contexts really expect rvalues for presentation purposes. Fixes rdar://problem/17057039.
Swift SVN r21549
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
reserve ? itself as a special token that cannot be defined (protecting ternary, postfix ?,
etc) but add some defensive code to prevent people from defining those operators.
<rdar://problem/17923322> allow ? as a general operator character
Swift SVN r21051
Start capitalizing on some of the new diagnostic machinery in a few different ways:
- When mining constraints for type information, utilize constraints "favored" by the overload resolution process.
- When printing type variables, if the variable was created by opening a literal expression, utilize the literal
default type or conformance if possible.
- Utilize syntactic information when crafting diagnostics:
- If the constraint miner can produce a better diagnostic than the recorded failure, diagnose via constraints.
- Factor in the expression kind when choosing which types to include in a diagnostic message.
- Start customizing diagnostics based on the amount of type data available.
What does all this mean?
- Fewer type variables leaking into diagnostic messages.
- Far better diagnostics for overload resolution failures. Specifically, we now print proper argument type data
for failed function calls.
- No more "'Foo' is not convertible to 'Foo'" error messages
- A greater emphasis on type data means less dependence on the ordering of failed constraints. This means fewer
inscrutable diagnostics complaining about 'UInt8' when all the constituent expressions are of type Float.
So we still have a ways to go, but these changes should greatly improve the number of head-scratchers served up
by the type checker.
These changes address the following radars:
rdar://problem/17618403
rdar://problem/17559042
rdar://problem/17007456
rdar://problem/17559042
rdar://problem/17590992
rdar://problem/17646988
rdar://problem/16979859
rdar://problem/16922560
rdar://problem/17144902
rdar://problem/16616948
rdar://problem/16756363
rdar://problem/16338509
Swift SVN r20927
Change the lexing of '?' to be similar to '!', where we special-case the postfix case for the intrinsic postfix optional operator, but fall back to lexing as an operator when it isn't left-bound. For now, only accept '??' as an operator name--we could easily generalize this, but that warrants discussion first.
Swift SVN r20591
enforce its own little constraints. The type checker isn't using it for
anything, and it is just clutter.
This resolves <rdar://problem/16656024> Remove @assignment from operator implementations
Swift SVN r19960
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
expression applications
(rdar://problem/15933674, rdar://problem/17365394 and many, many dupes.)
When solving for the type of a binOp expression, factor the operand expression
types into account when collating overloads for the operator being applied.
This allows the type checker to now infer types for some binary operations with
hundreds of nested components, whereas previously we could only handle a handful.
(E.g., "1+2+3+4+5+6" previously sent the compiler into a tailspin.)
Specifically, if one of the operands is a literal, favor operator overloads
whose operand, result or contextual types are the default type of the literal
convertible conformance of the the argument literal type.
By doing so we can prevent exponential behavior in the solver and massively
reduce the complexity of many commonly found constraint systems. At the same
time, we'll still defer to "better" overloads if the default one cannot be
applied. (When adding an Int8 to an Int, for example.)
This obviously doesn't solve all of our performance problems (there are more
changes coming), but there are couple of nice side-effects:
- By tracking literal/convertible protocol conformance info within type
variables, I can potentially eliminate many instances of "$T0" and the
like from our diagnostics.
- Favored constraints are placed at the front of the overload resolution
disjunction, so if a system fails to produce a solution they'll be the
first to be mined for a cause. This helps preserve user intent, and leads
to better diagnostics being produced in some cases.
Swift SVN r19848
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
This consolidates the \x, \u, and \U escape sequences into one \u{abc} escape sequence.
For now we still parse and cleanly reject the old forms with a nice error message, this
will eventually be removed in a later beta (tracked by rdar://17527814)
Swift SVN r19435
We haven't been advertising this syntax much, and it's closure form
was completely broken anyway, so don't jump through hoops to provide
great Fix-Its here.
Swift SVN r19277
DiscardAssignment expressions are special in that during constraint generation they'll introduce a new type variable, but not place any constraints upon it. (They are the only expression kind that behaves in this way.) If no subsequent expressions constrain the type variable, we may end up with a failed constraint system that's devoid of constraints, and hence no information to synthesize a diagnostic from. With no diagnostic associated with the DiscardAssignmentExpr's source location, we'll attempt to generate SIL and raise an assertion failure. Fortunately, we can detect these cases during the constraint salvage phase, and raise an appropriate error.
Swift SVN r19020
One difficulty in generating reasonable diagnostic data for type check failures has been the fact that many constraints had been synthesized without regard for where they were rooted in the program source. The result of this was that even though we would store failure information for specific constraints, we wouldn't emit it for lack of a source location. By making location data a non-optional component of constraints, we can begin diagnosing type check errors closer to their point of failure.
Swift SVN r18751
- rdar://problem/16776273, wherein conversions between nil and .None were permitted
due to an implicit conversion between nil and COpaquePointer.
- rdar://problem/16877526, where we needed to add new equality overloads to handle
conversions between nil and .None given the supression of user conversions.
(Some minor tweaks this time around for better interoperability with AnyObject.)
Swift SVN r18498
- rdar://problem/16776273, wherein conversions between nil and .None were permitted
due to an implicit conversion between nil and COpaquePointer.
- rdar://problem/16877526, where we needed to add new equality overloads to handle
conversions between nil and .None given the supression of user conversions.
(Thanks to Ted for the overloads and test.)
Swift SVN r18473
I didn't want to rip this logic out wholesale. There is a possibility
the character lexing can be reborn/revisited later, and
disabling it in the parser was easy.
Swift SVN r18102
There's a lot more work to do here, but start to categorize tests
along the lines of what a specification might look like, with
directories (chapters) for basic concepts, declarations, expressions,
statements, etc.
Swift SVN r9958
