This was one of our most visible user-facing crashers, manifesting itself any time a user performed an equality comparison on an unresolved enum case.
Swift SVN r24753
Instead, just check the generic parameters, then do a lookup as usual in the
enclosing context.
Fixes crash suite #58 and quite a few others (~200). This looks way more
impressive than it is; in most of these test cases it's the exact same
pattern causing the crash, and that pattern was just the last outstanding
crash trigger in a sea of garbage. (The few deleted tests were identical
to #58.)
Swift SVN r24748
func a(b: Int = 0) {}
let c = a // should be (b: Int) -> Void, not (b: Int = 0) -> Void
Fixes crash suite #23.
rdar://problem/18232797
Swift SVN r24747
UTF16.{leadSurrogate,trailSurrogate} were converting intermediate
results to UInt16 too soon, causing a trap on U+20000 and higher.
rdar://19156359
Swift SVN r24678
Bitwise operations on Bool are redundant with other logic operations
that stdlib already provides. The only reason to have them was to avoid
branching in the short-circuiting && and ||.
rdar://19340952
Surprisingly, replacing & and | in the standard library with && and ||
brought performance improvements and no significant performance
regressions:
RecursiveOwnedParameter 1.14
SelectionSort 1.19
Swift SVN r24674
Ugly (both in layout and functionality) workaround for Gyb rdar://15928178, using operator if/else if/else instead of if/elif statements;
this was fiddly to get working, hence the separate check-in.
Sharpen the expected error string for mixed type operators, and add an expected warning and note for assigning the result of
an assignment, which is righteous since we're not C.
Approved by Dmitri.
Swift SVN r24586
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
Require 'as' when converting from Objective-C type to native type (but
continue to allow implicit conversion from native to Objective-C). This
conversion constraint is called ExplicitConversion; all implicit
conversions are covered by the existing Conversion constraint. Update
standard library and tests to match.
Swift SVN r24496
This fast path is only taken when the code is specialized.
Fixes <rdar://problem/19331717> Optimizer breaks Set<T> and Dictionary<K, V>
Swift SVN r24479
I'm not sure how this ever worked -- it was previously always parsing the
OS X standard library but with the current target's triple.
Should fix the buildbot.
Swift SVN r24472
When dealing with multiple levels of generic parameters, the mapping
from potential archetypes down to actual archetypes did not have
access to the archetypes for outer generic parameters. When same-type
requirements equated a type from the inner generic parameter list with
one from the outer generic parameter list, the reference to the outer
generic parameter list's type would remain dependent. For example,
given:
struct S<A: P> {
init<Q: P where Q.T == A>(_ q: Q) {}
}
we would end up with the dependent type for A (τ_0_0) in the same-type
constraint in the initializer requirement.
Now, notify the ArchetypeBuilder of outer generic signatures (and,
therefore, outer generic parameters), so that it has knowledge of the
mapping from those generic parameters to the corresponding
archetypes. Use that mapping when translating potential archetypes to
real archetypes. Additionally, when a potential archetype is mapped to
a concrete type (via a same-type constraint to a concrete type),
substitute archetypes for any dependent types within the concrete
type.
Remove a bunch of hacks in the compiler that identified dependent
types in "strange" places and tried to map them back to
archetypes. Those hacks handled some narrow cases we saw in the
standard library and some external code, but papered over the
underlying issue and left major gaps.
Sadly, introduce one hack into the type checker to help with the
matching of generic witnesses to generic requirements that follow the
pattern described above. See ConstraintSystem::SelfTypeVar; the proper
implementation for this matching involves substituting the adoptee
type in for Self within the requirement, and synthesizing new
archetypes from the result.
Fixes rdar://18435371, rdar://18803556, rdar://19082500,
rdar://19245317, rdar://19371678 and a half dozen compiler crashers
from the crash suite. There are a few other radars that I suspect this
fixes, but which require more steps to reproduce.
Swift SVN r24460
failure
Certain iOS simulator versions have a bug in 'simctl' that prevents it
from propagating the exit code to lit in all cases. We are not running
these iOS versions on the buildbots yet.
rdar://19408362
Swift SVN r24369
This reverts commit r23030.
This puts non-primary archetypes back in the all-archetypes list,
which is the deepest underlying problem behind
rdar://problem/19049566.
Conflicts:
lib/AST/ArchetypeBuilder.cpp
validation-test/compiler_crashers/0033-error.swift
validation-test/compiler_crashers/035-multiple-typecheck-segfault.swift
Swift SVN r24333
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
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
Replace hard-coded lists of real-number types, and of arithmetic and logical operators I’m testing, with lists added to SwiftIntTypes.py, which becomes a bit of a misnomer.
Separate them into ones which only work on integer types, and those which also allow reals.
Do a double loop, over just the integers and then the reals as well.
Change the run line to allow importing StdlibUnittest with help from Dmitri, which I won't actually need until I do result type checking.
Approved by Dmitri.
Swift SVN r24029
These changes make the following improvements to how we generate diagnostics for expression typecheck failure:
- Customizing a diagnostic for a specific expression kind is as easy as adding a new method to the FailureDiagnosis class,
and does not require intimate knowledge of the constraint solver’s inner workings.
- As part of this patch, I’ve introduced specialized diagnostics for call, binop, unop, subscript, assignment and inout
expressions, but we can go pretty far with this.
- This also opens up the possibility to customize diagnostics not just for the expression kind, but for the specific types
involved as well.
- For the purpose of presenting accurate type info, partially-specialized subexpressions are individually re-typechecked
free of any contextual types. This allows us to:
- Properly surface subexpression errors.
- Almost completely avoid any type variables in our diagnostics. In cases where they could not be eliminated, we now
substitute in "_".
- More accurately indicate the sources of errors.
- We do a much better job of diagnosing disjunction failures. (So no more nonsensical ‘UInt8’ error messages.)
- We now present reasonable error messages for overload resolution failures, informing the user of partially-matching
parameter lists when possible.
At the very least, these changes address the following bugs:
<rdar://problem/15863738> More information needed in type-checking error messages
<rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
<rdar://problem/16449805> Wrong error for struct-to-protocol downcast
<rdar://problem/16699932> improve type checker diagnostic when passing Double to function taking a Float
<rdar://problem/16707914> fatal error: Can't unwrap Optional.None…Optional.swift, line 75 running Master-Detail Swift app built from template
<rdar://problem/16785829> Inout parameter fixit
<rdar://problem/16900438> We shouldn't leak the internal type placeholder
<rdar://problem/16909379> confusing type check diagnostics
<rdar://problem/16951521> Extra arguments to functions result in an unhelpful error
<rdar://problem/16971025> Two Terrible Diagnostics
<rdar://problem/17007804> $T2 in compiler error string
<rdar://problem/17027483> Terrible diagnostic
<rdar://problem/17083239> Mysterious error using find() with Foundation types
<rdar://problem/17149771> Diagnostic for closure with no inferred return value leaks type variables
<rdar://problem/17212371> Swift poorly-worded error message when overload resolution fails on return type
<rdar://problem/17236976> QoI: Swift error for incorrectly typed parameter is confusing/misleading
<rdar://problem/17304200> Wrong error for non-self-conforming protocols
<rdar://problem/17321369> better error message for inout protocols
<rdar://problem/17539380> Swift error seems wrong
<rdar://problem/17559593> Bogus locationless "treating a forced downcast to 'NSData' as optional will never produce 'nil'" warning
<rdar://problem/17567973> 32-bit error message is really far from the mark: error: missing argument for parameter 'withFont' in call
<rdar://problem/17671058> Wrong error message: "Missing argument for parameter 'completion' in call"
<rdar://problem/17704609> Float is not convertible to UInt8
<rdar://problem/17705424> Poor error reporting for passing Doubles to NSColor: extra argument 'red' in call
<rdar://problem/17743603> Swift compiler gives misleading error message in "NSLayoutConstraint.constraintsWithVisualFormat("x", options: 123, metrics: nil, views: views)"
<rdar://problem/17784167> application of operator to generic type results in odd diagnostic
<rdar://problem/17801696> Awful diagnostic trying to construct an Int when .Int is around
<rdar://problem/17863882> cannot convert the expression's type '()' to type 'Seq'
<rdar://problem/17865869> "has different argument names" diagnostic when parameter defaulted-ness differs
<rdar://problem/17937593> Unclear error message for empty array literal without type context
<rdar://problem/17943023> QoI: compiler displays wrong error when a float is provided to a Int16 parameter in init method
<rdar://problem/17951148> Improve error messages for expressions inside if statements by pre-evaluating outside the 'if'
<rdar://problem/18057815> Unhelpful Swift error message
<rdar://problem/18077468> Incorrect argument label for insertSubview(...)
<rdar://problem/18079213> 'T1' is not identical to 'T2' lacks directionality
<rdar://problem/18086470> Confusing Swift error message: error: 'T' is not convertible to 'MirrorDisposition'
<rdar://problem/18098995> QoI: Unhelpful compiler error when leaving off an & on an inout parameter
<rdar://problem/18104379> Terrible error message
<rdar://problem/18121897> unexpected low-level error on assignment to immutable value through array writeback
<rdar://problem/18123596> unexpected error on self. capture inside class method
<rdar://problem/18152074> QoI: Improve diagnostic for type mismatch in dictionary subscripting
<rdar://problem/18242160> There could be a better error message when using [] instead of [:]
<rdar://problem/18242812> 6A1021a : Type variable leaked
<rdar://problem/18331819> Unclear error message when trying to set an element of an array constant (Swift)
<rdar://problem/18414834> Bad diagnostics example
<rdar://problem/18422468> Calculation of constant value yields unexplainable error
<rdar://problem/18427217> Misleading error message makes debugging difficult
<rdar://problem/18439742> Misleading error: "cannot invoke" mentions completely unrelated types as arguments
<rdar://problem/18535804> Wrong compiler error from swift compiler
<rdar://problem/18567914> Xcode 6.1. GM, Swift, assignment from Int64 to NSNumber. Warning shown as problem with UInt8
<rdar://problem/18784027> Negating Int? Yields Float
<rdar://problem/17691565> attempt to modify a 'let' variable with ++ results in typecheck error about @lvalue Float
<rdar://problem/17164001> "++" on let value could give a better error message
Swift SVN r23782
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
Add all compiler crash tests to the validation-test/compiler_crashers
subdirectory. Add a RUN: line to each test case according to the current
behavior of the Swift compiler.
Swift SVN r23418
