Co-authored-by: mjmahone <[email protected]>

at least for now!

* implement execution for fragment arguments syntax

Co-authored-by: mjmahone <[email protected]>

* add directive test (#9)

* add directive test

* add failing test

add additional nested fragment test (#8)

Correct test and lint stuff

suggestions for execution (#11)

* introduce internal getVariableSignature utility

now extracted also to graphql-js PR, see graphql#4175

* execution suggestions

fixes execution to always use fragment variable when has the same name as an operation variable

previously, we were allowing an operation variable to be used if the fragment variable was not provided, and the field had no default. Now, we still use the fragment variable, and so the value is null.

this now correct logic allows us to significantly reduce the diff from main

adds additional test

* move getVariableSignature to execution

as it cannot be used by validation, which must collect all errors rather than fail with invalid type for signature

---------

Co-authored-by: mjmahone <[email protected]>
Co-authored-by: Yaacov Rydzinski <[email protected]>

* Add typeinfo functionality as a run-up to supporting the new validation
rules

Co-authored-by: mjmahone <[email protected]>

* Fragment arguments validation (#5)

* Fragment args validation

* add experimental substitution

* validation suggestions (#12)

* validation suggestions

* remove OperationSignature from ValidationContext

only used in one rule, does not need to be on context

remove dependency on getVariableSignature

move FRAGMENT_ARGUMENT below ARGUMENT

fragment arguments do not have location defaults

only variable defaults => so getDefaultValue(), which returns location defaults for use with the allowedVariableUsage helper, should never be called by getVariableUsages with respect to fragment arguments

fragment arguments therefore need not add anything to the default value stack

reduce diff from main

these diffs crept in before Kind.FRAGMENT_ARGUMENT was separated out

---------

Co-authored-by: Yaacov Rydzinski <[email protected]>

* OverlappingFieldsCanBeMergedRule suggestions (#15)

---------

Co-authored-by: mjmahone <[email protected]>
Co-authored-by: Yaacov Rydzinski <[email protected]>