Skip to content

RequirementMachine: Improved modeling of concrete conformances #40425

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 11 commits into from
Dec 8, 2021

Conversation

slavapestov
Copy link
Contributor

@slavapestov slavapestov commented Dec 6, 2021

Introduces a new symbol kind, the "concrete conformance symbol". This combines a concrete type with a protocol, and can appear in property rules, like so:

T.[concrete: C : P] => T

These rules are introduced by property map construction when the same key is known to have a concrete type requirement together with a conformance requirement. Together with the new rule, property map construction also adds a rewrite loop that relates the concrete type rule, the protocol conformance rule and the concrete conformance rule together:

(T => T.[P]) * (T => T.[concrete: C]).[P] * T.([concrete: C].[P] => [concrete: C : P]) * (T.[concrete: C : P] => T)

The rewrite step ([concrete: C].[P] => [concrete: C : P]) does not correspond to a rewrite rule, but is rather a special new kind RewriteStep::ConcreteConformance. It converts a pair of symbols, a concrete type symbol and a protocol symbol, into a concrete conformance symbol (or vice versa, when the step is inverted).

Similarly for superclasses, there is a new RewriteStep::SuperclassConformance which converts ([superclass: C].[P]) into [concrete: C : P].

Note that in the new rewrite loop, the protocol conformance and concrete conformance rules appear in empty context, and the concrete type rule appears in context. This means the loop can be used to eliminate either the protocol conformance or the concrete conformance rules.

Concrete conformance symbols order before protocol conformance symbols, so a rule T.[concrete: C : P] => T orders before T.[P] => T. This means generating conformances will prefer to mark the latter as redundant, if possible.

Putting everything together, this means that given a signature like

<T where T : Sequence, T : Array<Int>>

The T : Sequence requirement will become redundant. The minimized rewrite system will also have the concrete conformance rule. Since there is no such thing as a "concrete conformance requirement" in generic signatures, these rules are just dropped for now.

@slavapestov slavapestov force-pushed the rqm-concrete-conformance branch from c30c07d to 0e6d95d Compare December 6, 2021 08:18
…Evaluator

This better encapsulates the evaluator state into a single struct.
For homotopy reduction to properly deal with rewrite rules
introduced by property map construction, we need to keep
track of the original property rules when recording properties
in property bags.

For now, this doesn't even attempt to handle unification or
conflicts; we only record the first rule for each kind of
property on a fixed key.

This isn't actually used for anything yet, except a new
verify pass that runs after property map construction.
@slavapestov slavapestov force-pushed the rqm-concrete-conformance branch from 0e6d95d to 8e83795 Compare December 7, 2021 04:06
@slavapestov slavapestov force-pushed the rqm-concrete-conformance branch from 8e83795 to 26293c4 Compare December 7, 2021 21:20
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov slavapestov marked this pull request as ready for review December 8, 2021 02:10
@slavapestov slavapestov merged commit 81ac321 into swiftlang:main Dec 8, 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