-
Notifications
You must be signed in to change notification settings - Fork 101
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
Traits unification #1625
Traits unification #1625
Conversation
Co-authored-by: chriseth <[email protected]>
Just saw that side_effect_check also needs to take the impls into account. Maybe there is some code to be shared between side_effect_check and the trait checks? |
pil-analyzer/src/pil_analyzer.rs
Outdated
// We filter out enum type declarations (the constructor functions have been added | ||
// by the statement processor already). | ||
// For Arrays, we also collect the inner expressions and expect them to be field elements. | ||
|
||
for (name, trait_impls) in self.implementations.iter_mut() { | ||
let (_, def) = self | ||
.definitions | ||
.get(name) | ||
.get_mut(name) |
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.
Why do you need a mutable reference 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.
The generic type that I am going to “specialize” using the implementation, is stored in the trait declaration, that's why the mutability.
pil-analyzer/src/traits_resolver.rs
Outdated
.function_by_name_mut(&named_expr.name) | ||
.expect("Function not found in trait declaration"); | ||
|
||
trait_fn.ty.substitute_type_vars(&type_var_mapping); |
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.
Ah, now I see! Does it even have a type? Shouldn't we just take the type from the trait and then let the type inferenec algorithm do its job?
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.
I.e. just return trait_type.clone().substitute_type_vars(&type_var_mapping)
?
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.
And then I think the type inference algorithm will store the type anyway at the end.
ast/src/parsed/mod.rs
Outdated
panic!("Expected trait declaration"); | ||
}; | ||
|
||
pub fn specialize_trait_type(&self, trait_decl: &TraitDeclaration, fn_name: &str) -> Type { |
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.
Nice! And now I think we could rename this to type_of_function
.
pil-analyzer/src/pil_analyzer.rs
Outdated
@@ -220,7 +220,9 @@ impl PILAnalyzer { | |||
for impl_ in impls { |
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.
Is this inside the loop over the definitions?
No description provided.