Skip to content

[GSB] Keep track of all layout constraints. #8241

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 1 commit into from
Mar 21, 2017

Conversation

DougGregor
Copy link
Member

As we've done with all of the other kinds of constraints, keep track
of all of the layout constraints on the equivalence class. Use the
normal mechanism to diagnose conflicts between different layout
constraints, warn about duplicate layout constraints, etc.

As we've done with all of the other kinds of constraints, keep track
of all of the layout constraints on the equivalence class. Use the
normal mechanism to diagnose conflicts between different layout
constraints, warn about duplicate layout constraints, etc.
@DougGregor
Copy link
Member Author

@swiftix , you'll be interested in this. Also, layout constraints seem to be a bit unfinished. Here's a laundry list of things I expected but didn't see for layout constraints:

  • "Merging" rules for layout constraints, e.g., if both a _Trivial constraint and a _Trivial(64) constraint appear on a type parameter, it's not wrong... but we should keep _Trivial(64). Similarly for ref-counted/native-ref-counted
  • The presence of a same-type-to-concrete or superclass constraint could imply a layout constraint, e.g., a superclass constraint implies _RefCounted. This should be modeled in the GSB directly, because it affects minimization.
  • Similar to the second bullet but also interesting... are there cases where a same-type-to-concrete constraint does not imply a specific layout, i.e., the layout constraint is added? Such constraints will currently get dropped, which is going to be a problem for minimization.

@DougGregor
Copy link
Member Author

@swift-ci please smoke test and merge

@swift-ci swift-ci merged commit 9ad340e into swiftlang:master Mar 21, 2017
@DougGregor DougGregor deleted the all-layout-constraints branch March 21, 2017 14:31
swiftix added a commit to swiftix/swift that referenced this pull request Mar 22, 2017
This PR addresses TODOs from swiftlang#8241.

- It supports merging for layout constraints, e.g., if both a _Trivial constraint and a _Trivial(64) constraint appear on a type parameter, we keep only _Trivial(64) as a more specific layout constraint. We do a similar thing for ref-counted/native-ref-counted. The overall idea is to keep the more specific of two compatible layout constraints.
- The presence of a superclass constraint implies a layout constraint, e.g., a superclass constraint implies _Class or _NativeClass
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