Skip to content

[GenericSignatureBuilder] Remove self-derived same-type-to-concrete constraints. #7812

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 7 commits into from
Feb 28, 2017

Conversation

DougGregor
Copy link
Member

Introduce an operation on RequirementSource to determine whether a
constraint with such a source, when it lands on a given potential
archetype, is "self-derived": e.g., the final constraint is derived
from the original constraint. Remove such constraints from the system
during finalization, because otherwise they would make the original
constraint redundant.

To get here, extend RequirementSource to store the root PotentialArchetype (on which the constraint was generated) as well as the AssociatedTypeDecl for each nested type access. We can now follow the paths more predictably.

Fixes rdar://problem/30478915, although we still need to apply this
same logic to other kinds of constraints in the system.

Whenever we create a (root) requirement source, associate it with the
potential archetype on which the requirement is written. This lets us
follow a requirement source from the (stated or implied) requirement on
the root potential archetype to the effective requirement on the
resulting potential archetype.

Introduce FloatingRequirementSource for the cases where we need to
state what the root source is, but don't yet have a potential
archetype to attach it to. These get internally resolved to
RequirementSources as soon as possible.
Use TrailingObjects to help us efficiently store the root potential
archetype within requirement sources, so we can reconstruct the
complete path from the point where a requirement was created to the
potential archetype it affects.

The test changes are because we are now dumping the root potential
archetype as part of -debug-generic-signatures.
Introduce an operation on RequirementSource to determine whether a
constraint with such a source, when it lands on a given potential
archetype, is "self-derived": e.g., the final constraint is derived
from the original constraint. Remove such constraints from the system
during finalization, because otherwise they would make the original
constraint redundant.

Fixes rdar://problem/30478915, although we still need to apply this
same logic to other kinds of constraints in the system.
@DougGregor DougGregor force-pushed the self-derived-constraints branch from 2b94c65 to 5ec3857 Compare February 28, 2017 17:48
@DougGregor DougGregor changed the title [GSB] Remove self-derived same-type-to-concrete constraints. [GenericSignatureBuilder] Remove self-derived same-type-to-concrete constraints. Feb 28, 2017
@DougGregor
Copy link
Member Author

@swift-ci please smoke test and merge

@DougGregor
Copy link
Member Author

DougGregor commented Feb 28, 2017

@shahmishal, any idea why I'm unable to trigger CI?

@DougGregor
Copy link
Member Author

@swift-ci please smoke test and merge

@shahmishal
Copy link
Member

GitHub Status (https://status.github.com/messages)

10:00 PST We are investigating issues serving web hooks as well as assets on GitHub.com.

@DougGregor DougGregor merged commit 1c6757f into swiftlang:master Feb 28, 2017
@DougGregor DougGregor deleted the self-derived-constraints branch February 28, 2017 19:22
@DougGregor
Copy link
Member Author

Okay, thank you @shahmishal !

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.

2 participants