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
