...into the validation suite. This is the wrong solution but at least
the bots will continue to run all the tests and we won't regress.
Swift SVN r24934
Addressing rdar://problem/19434979 will allow us to swizzle expected errors based on build configuration options,
but until I can push that change we should generalize a few of the expected errors in the FixedPointDiagnostics test,
and re-enable the test on ARM.
Swift SVN r24910
Parser may stop at some erroneous constructions like stray #else or #endif, in some cases closing brace ‘}’, etc…
continue parsing until we are done.
Swift SVN r24822
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
