Open Radar

 
Summary:
The compiler crashes when it tries to diagnose the failure to solve an expression involving && in the presence of an overload. Sometimes it doesn’t crash, so there’s actually a race condition, which impresses me.


Steps to Reproduce:
1. Compile this program:

func == <T> (T, T) -> Bool {
	return reduce(map("") { _ in false }, true, &&)
}

func && <T, U> ([T], [U]) -> [(T, U)] { return [] }


Expected Results:
Either for it to typecheck & compile or for it to print out the reason why it doesn’t typecheck.


Actual Results:
Quite a lovely crash down a fairly deep callstack. Except when it _does_ print out the valid errors:

a.swift:2:46: error: argument for generic parameter 'T' could not be inferred
        return reduce(map("") { _ in false }, true, &&)
                                                    ^
a.swift:5:6: note: in call to operator '&&'
func && <T, U> ([T], [U]) -> [(T, U)] { return [] }
     ^

But usually (9 times out of 10? More?) it crashes.


Regression:
It doesn’t crash if there’s no overload of &&.
It doesn’t crash if the return type of && has includes only T or U; as originally written, this crashed with Either<T, U>, and it also crashed with DictionaryIndex<T, U>.
You don’t actually have to provide a valid implementation of &&—you can return a string (just don’t change the return type) and it will still crash.


Notes:
Fun fact™: The race condition crashed about half the time as originally written, this reduction crashes it almost every time.

This is blocking me.