Before we extracted all the subexpressions from the `SequenceExpr` while we should've only extracted the expressions at odd indices:
```
...
/// SequenceExpr - A list of binary operations which has not yet been
/// folded into a tree. The operands all have even indices, while the
/// subexpressions with odd indices are all (potentially overloaded)
/// references to binary operators.
class SequenceExpr final : public Expr,
...
```
The AST for a `SequenceExpr` looks like this:
```
sequence_expr:
unresolved_dot_expr:
...
assign_expr:
member_ref_expr:
...
dot_syntax_call_expr:
...
unresolved_member_chain_expr:
...
```
however, what's is not visible with the "final" AST is that `unresolved_dot_expr` is the unresolved version of `assign_expr.member_ref_expr` and the `unresolved_member_chain_expr` is the unresolved version of `assign_expr.dot_syntax_call_expr`.
This becomes visible when I enable typechecker debugging:
```c++
auto &typeCheckerOptions = invocation.getTypeCheckerOptions();
typeCheckerOptions.DebugConstraintSolver = true;
```
Which prints the following snippets:
```
---Initial constraints for the given expression---
(assign_expr type='()' location=foo.swift:25:54 range=[foo.swift:25:13 - line:25:57]
(unresolved_dot_expr type='$T2' location=foo.swift:25:29 range=[foo.swift:25:13 - line:25:29] field 'preferredDatePickerStyle' function_ref=unapplied
(unresolved_dot_expr type='$T1' location=foo.swift:25:18 range=[foo.swift:25:13 - line:25:18] field 'datePicker' function_ref=unapplied
(declref_expr type='DatePickerCell' location=foo.swift:25:13 range=[foo.swift:25:13 - line:25:13] decl=foo.(file).DatePickerRowProtocol extension.configurePickerStyle(_:_:).cell@foo.swift:15:33 function_ref=unapplied)))
(unresolved_member_chain_expr implicit type='$T5' location=foo.swift:25:57 range=[foo.swift:25:56 - line:25:57]
(unresolved_member_expr type='$T4' location=foo.swift:25:57 range=[foo.swift:25:56 - line:25:57] name='wheels' function_ref=unapplied)))
// ...
---Type-checked expression---
(assign_expr type='()' location=foo.swift:25:54 range=[foo.swift:25:13 - line:25:57]
(member_ref_expr type='@lvalue UIDatePickerStyle' location=foo.swift:25:29 range=[foo.swift:25:13 - line:25:29] decl=UIKit.(file).UIDatePicker.preferredDatePickerStyle
(force_value_expr implicit type='UIDatePicker' location=foo.swift:25:18 range=[foo.swift:25:13 - line:25:18] implicit_iuo_unwrap
(load_expr implicit type='UIDatePicker?' location=foo.swift:25:18 range=[foo.swift:25:13 - line:25:18]
(member_ref_expr type='@lvalue UIDatePicker?' location=foo.swift:25:18 range=[foo.swift:25:13 - line:25:18] decl=foo.(file).DatePickerCell.datePicker@foo.swift:10:29
(declref_expr type='DatePickerCell' location=foo.swift:25:13 range=[foo.swift:25:13 - line:25:13] decl=foo.(file).DatePickerRowProtocol extension.configurePickerStyle(_:_:).cell@foo.swift:15:33 function_ref=unapplied)))))
(dot_syntax_call_expr type='UIDatePickerStyle' location=foo.swift:25:57 range=[foo.swift:25:56 - line:25:57]
(declref_expr type='(UIDatePickerStyle.Type) -> UIDatePickerStyle' location=foo.swift:25:57 range=[foo.swift:25:57 - line:25:57] decl=UIKit.(file).UIDatePickerStyle.wheels function_ref=unapplied)
(argument_list implicit
(argument
(type_expr implicit type='UIDatePickerStyle.Type' location=foo.swift:25:56 range=[foo.swift:25:56 - line:25:56] typerepr='UIDatePickerStyle')))))
```
The proposed solution is to only extract subexpressions at indices from `SequenceExpr` thus ignoring all the unresolved leftovers.
Note: I'm not entirely sure about the case when there is only child (`elements.size() == 1`) so I'm always extracting it.
This patch fixes the last source of unresolved expressions.
Allow empty lines while looking for diff (between `---expected` and `FAILED`). This can happen when there is `Locations outside the test directory` since an empty line is printed after that warning message (this output can be interleaved with the diff due to parallel execution).
In master, we need to switch to these, but for building for older
versions we need to add our own support.
Currently the v_1_9_255 files are nto used, but we will need them (in a
differently-named directory) for a future release.
