-
Notifications
You must be signed in to change notification settings - Fork 56
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
Support for Exponents #484
Conversation
Implement the mux builtin
If one of the types is generics (because it was builtin) it will not be cast.
Added the variadics to the index members to allow the resolver to correctly address them / modify them once a generic type needs to be replaced
The MUX, SEL and MOVE functions will have their own annotations This allows more control on the return types of the functions
The return type for builtins is now correctly annotated, the special annotation is not yet used, will be needed for EXPT
…ively only the expt does it differently
…er cases are handled by reals
Codecov Report
@@ Coverage Diff @@
## master #484 +/- ##
==========================================
+ Coverage 89.01% 89.07% +0.05%
==========================================
Files 42 42
Lines 15261 15366 +105
==========================================
+ Hits 13585 13687 +102
- Misses 1676 1679 +3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it 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.
2 tiny things, rest looks good to me!
generics_candidates.insert("U".to_string(), vec![element_type.to_string()]); | ||
generics_candidates.insert("V".to_string(), vec![exponant_type.to_string()]); | ||
annotator.update_generic_call_statement(generics_candidates, "EXPT", operator, parameters, ctx) | ||
} |
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 an else here unreachable? can we add an !impossible with explanation?
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 added an unreachable here, but I'm not sure this is the best way.
Theoratically these types exist, and if not it's the resolver's / validator's job to say so.
Adds support for exponents as defined in the norm (
3**2
is 3 to the power of 2)The implementation will call the appropriate EXPT function from the standard functions
It attempts to find the most efficient function for the input (int powers, or real powers)
The actual methods are implemented in the standard functions :
PLC-lang/StandardFunctions#48