Skip to content
This repository has been archived by the owner on Jan 25, 2018. It is now read-only.

Skip superfluous and error-prone variable reference check. #222

Merged
merged 1 commit into from Sep 22, 2017

Conversation

mcovarr
Copy link
Contributor

@mcovarr mcovarr commented Sep 19, 2017

Addresses the issue found in this forum post.

@geoffjentry
Copy link
Contributor

geoffjentry commented Sep 19, 2017

👍

Approved with PullApprove

// the namespace's descendants: once with a parent that is the containing static workflow and again with a parent that is the dynamic workflow
// call. Looking for variable references when the parent is a workflow call will fail if the variable references a call output since only
// declarations are made children of workflow calls. This variable reference check is also redundant to the check that will happen with the
// copy of the declaration that has a static workflow parent.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This look like it should be a single javadoc style comment since it should be considered attached to the parentIsNotAWorkflowCall method

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an internal function and wouldn't render as Scaladoc, but I could certainly use the multi-line syntax if that was deemed more palatable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite my previous thumb I'll chime in to say that I concur in that I prefer

 /*
    foo
 */

for multiline comments. I realize that wasn't a multiline comment :)

// call. Looking for variable references when the parent is a workflow call will fail if the variable references a call output since only
// declarations are made children of workflow calls. This variable reference check is also redundant to the check that will happen with the
// copy of the declaration that has a static workflow parent.
def parentIsNotAWorkflowCall(declaration: DeclarationInterface): Boolean = declaration.parent.collect({ case p: WdlWorkflowCall => p }).isEmpty
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filterByType[WdlWorkflowCall]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re previous conversation, since it's an Option I think I'd lean towards a match here after all

val invalidVariableReferences = for {
expr <- declaration.expression.toSeq
variable <- referencesToAbsentValues(declaration, expr)
variable <- referencesToAbsentValues(declaration, expr) if parentIsNotAWorkflowCall(declaration)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you do this check on line 344 (before we even call validateDeclaration) to avoid wasting the effort of re-validating any statically-validated declarations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it, I can try.

@mcovarr
Copy link
Contributor Author

mcovarr commented Sep 20, 2017

@cjllanwarne ready for final review.

Copy link
Contributor

@Horneth Horneth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing this ! :)
Could we have a test for it too ? A wdl4s unit test would be enough I think.

@mcovarr
Copy link
Contributor Author

mcovarr commented Sep 22, 2017

@Horneth I created a Centaur test for this.

@mcovarr mcovarr merged commit f57780c into develop Sep 22, 2017
@mcovarr mcovarr deleted the mlc_subworkflow_var_refs branch September 22, 2017 14:48
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants