Sema: Do not drop reference to type paramater if it reduces to ErrorType

[AnthonyLatsis]

Resolves #77840.

[AnthonyLatsis]

@swift-ci please smoke test

[slavapestov]

Given the original bug report:

Unhandled coercion:
(dependent_member_type assoc_type="test.(file).P.A@/Users/anthonylatsis/Desktop/test.swift:381:18"
  (base=existential_type
    (protocol_type decl="test.(file).P@/Users/anthonylatsis/Desktop/test.swift:380:10")))
(dependent_member_type assoc_type="test.(file).P.A@/Users/anthonylatsis/Desktop/test.swift:381:18"
  (base=opened_archetype_type address=0x14e170000 conforms_to="test.(file).P@/Users/anthonylatsis/Desktop/test.swift:380:10" opened_existential_id="F8EFB1A8-ABED-11EF-AA89-2E7849F3693B"
    (interface_type=generic_type_param_type depth=0 index=0 param_kind=type)
    (opened_existential=existential_type
      (protocol_type decl="test.(file).P@/Users/anthonylatsis/Desktop/test.swift:380:10"))))

I think the actual bug here is that we end up in CSApply even when the code was invalid. We should never have a DependentMemberType with a concrete base type like that.

[slavapestov]

Why is the behavior here any different than the case where Undefined exists?

[AnthonyLatsis]

The way I think about it is that if reduction returns an error type, then it makes sense to ignore the constraint that caused it to error out. That is, to not treat that error type as concrete when searching for type parameter references.

[AnthonyLatsis]

I think the actual bug here is that we end up in CSApply even when the code was invalid. We should never have a DependentMemberType with a concrete base type like that.

I will have a look at what the erasure algorithm is doing.

[AnthonyLatsis]

This is why we end up with up with an archetype base:

swift/lib/Sema/ConstraintSystem.cpp

Lines 1695 to 1700 in 42f0b89

	auto result = conformance.getTypeWitness(lookupBaseType, assocType);
	if (result && !result->hasError())
	return result;
	}
	return DependentMemberType::get(lookupBaseType, assocType);

[slavapestov]

Perhaps we shouldn’t proceed to CSApply if there are type variables with fixed types that contain dependent member types? We can treat them like free type variables perhaps.