Skip to content

RequirementMachine: More miscellaneous fixes #39189

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Sep 7, 2021

Conversation

slavapestov
Copy link
Contributor

Well, none of these changes actually touch the requirement machine implementation, only adjacent code. With these fixes, we're down to one validation test failure when the requirement machine is enabled.

…heritance clause

This enabled a gross idiom that should not have been allowed in the first place:

    typealias G<T> = Any where T : P

    protocol P {}
    protocol Q : G<Self> {} // Q inherits from P now!

I'd like to ban this, assuming nothing is actually relying on this behavior.
…closely

Extension binding and resolution of inherited protocols uses a more primitive
'declaration' based lookup that resolves a TypeRepr directly to a set of
NominalTypeDecls.

This lookup differs from type resolution in a few subtle ways, namely the
handling of ambiguity. In particular, if there are multiple declarations
with the same name, the primitive lookup returns all of them, since it
cannot perform the full ambiguity check done in type resolution, which
looks at typealias underlying types.

However, in the case where the multiple results are all nominal types, we
can definitely fail the 'decl' name lookup right away.
…iated types

If two associated types in an (invalid) protocol have the same name, use their
source location to order them instead of their memory address. This fixes a
non-deterministic test failure with the requirement machine enabled.
Now that directReferencesForTypeRepr() no longer returns
ambiguous results, move the special ambiguity diagnostic out
of CustomAttrNominalRequest::evaluate(), and instead
diagnose these situations in TypeCheckAttr.cpp.

Special-case the 'unknown type' diagnostic though, to report
'unknown attribute' in the common case where the name lookup
failed.
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov slavapestov merged commit a9fd623 into swiftlang:main Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant