-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[compiler-v2] Revise ability checking for type parameters #15006
Conversation
⏱️ 1h 30m total CI duration on this PR
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe an example where params_exempted is false would be useful to understand this better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also add this test to v1 so we can compare what V1 does with the example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Argh no. I do not add any tests to the deprecated code. I tested this manually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you are asking the reviewers to each go and manually test it to verify that your demonstrated behavior matches V1? That's pretty unhelpful. Please try to keep your emotions out of your work.
HasAbilities(AbilitySet), | ||
/// The type must have the given set of abilities. The boolean indicates whether | ||
/// type parameters are exempted. | ||
HasAbilities(AbilitySet, bool), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs more explanation, something like
(E.g., for type `S<T>` to have `drop`, ordinarily parameter `T` must also have `drop`,
but sometimes (???) we don't require that.)
But I hope you can fill in sometimes (???)
because I don't quite get it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I made an enum out of this, for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much nicer, thanks!
dfa8f11
to
2b45e76
Compare
@@ -519,7 +532,10 @@ impl Constraint { | |||
(Constraint::NoReference, Constraint::NoReference) => Ok(true), | |||
(Constraint::NoTuple, Constraint::NoTuple) => Ok(true), | |||
(Constraint::NoPhantom, Constraint::NoPhantom) => Ok(true), | |||
(Constraint::HasAbilities(a1), Constraint::HasAbilities(a2)) => { | |||
( | |||
Constraint::HasAbilities(a1, params_exempted1), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: maybe change the name params_exempted
to params_scope
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done already
@@ -573,23 +592,22 @@ impl Constraint { | |||
|
|||
/// Returns the constraints which need to be satisfied for a field type, | |||
/// given a struct with declared abilities. | |||
pub fn for_field(struct_abilities: AbilitySet, field_ty: &Type) -> Vec<Constraint> { | |||
pub fn for_field(struct_abilities: AbilitySet, _field_ty: &Type) -> Vec<Constraint> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need _field_ty
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may in the future, so keeping it.
Closes #14490 Move has some unusual semantics for ability checking of type parameters - In most contexts, a type parameter is assumed to have all abilities during checking. Then when the parameter is instantiated, checking takes place. - However, there is one exemption, namely when a type parameter is used to instantiate another type parameter which has an abilitie constraint, as in `f<T:drop>`. If we instantiate `f<R>` then `R` needs to be checked for `drop`. This PR solves this by adding a field `type_param_exempted` to `HasAbilities(abilities, type_param_exempted)` to the ability constraint.
2b45e76
to
f732c04
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
✅ Forge suite
|
Description
Closes #14490
Move has some unusual semantics for ability checking of type parameters
f<T:drop>
. If we instantiatef<R>
thenR
needs to be checked fordrop
.This PR solves this by adding a field
type_param_exempted
toHasAbilities(abilities, type_param_exempted)
to the ability constraint.How Has This Been Tested?
New baseline test, existing tests
Type of Change
Which Components or Systems Does This Change Impact?