-
Notifications
You must be signed in to change notification settings - Fork 16
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
Fix forward references in ExpressionBuilder #437
Fix forward references in ExpressionBuilder #437
Conversation
(and update the old 2.x bits of ELM that will never work anyway).
…97-fix-forward-references-in-expressionbuilder-2 # Conflicts: # Demo/Measures.Authoring/CSharp/FHIRHelpers-4.3.000.g.cs
…nces-in-expressionbuilder
I've identified a small issue where we are creating empty |
…fix-forward-references-in-expressionbuilder
…ttps://github.com/FirelyTeam/firely-cql-sdk into 397-fix-forward-references-in-expressionbuilder-2
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.
All tests pass. All HEDIS passes.
The merge-base changed after approval.
The merge-base changed after approval.
@EvanMachusak, none of the demo projects are able to rebuild as a result of the additional commits. Could you please have a look? Issue #450 |
@ewoutkramer I tried to duplicate the work into a new PR, but still getting stuck |
Fixes #397. Fixes #410.
This PR enables the translation of FunctionRef/ExpressionRef to rely on the ref's
resultTypeSpecifier
instead of having to look the definition up in the DefinitionDictionary. Not using the DefinitionDictionary avoids running into the situation where the ref is a forwards reference whereby the DefinitionDictionary does not yet contain the translated function we want to call.This PR uses the recent functionality added to LibrarySet to lookup a symbol, and expands this to be able to lookup functions by signature. Given the function name in the FUnctionRef/ExpressionRef, and, in the case of an overload, the signature, we can now lookup any function defined in any library in the LibrarySet, so we can copy over the resultTypeSpecifier.
Filling out this resultTypeSpecifier is now done in a pre-processing step, happening when we are constructing the LibrarySet. The pre-processing step will find all Refs, and then do this:
Otherwise, we cannot find the overload, and we will raise an error. This ensures that after the pre-processor has run, all Refs have a resultTypeSpecifier, and we can depend on that fact.
This PR re-uses the OverloadedFunctionDefinition, and there are some updates to the
CanCombine
function to make sure the pre-processor fix and the CanCombine use the same criteria.I also added a bunch of useful extension methods for working with the Elm function elements and signatures.