Allow fields with arguments in @requires #2120
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR allow the
fields
argument of a@requires
to require fields that are defined with arguments. If some of those argument are required, then those argument needs to be passed a value in the@requires
, while non-required argument can be passed a value but don't have to (and if no value is provided, they will be queried with their default value for the@requires
, exactly the same way that they would if they were queried directly).I'll note that this PR maintains the rejection of fields with arguments in
@key
and@provides
: we can lift the restriction for those directives later in separate PRs. In particular, that may be subjective, but allowing passing argument in@requires
feels a bit easier to reason about/understand to me than with@key
and@provides
, so it may be worth taking a bit more time to think about the implications of the later ones.For
@requires
, the code was mostly working out of the box, so the first commit mainly just 1) remove the validation that was rejecting it and 2) adds test coverage. However, adding it makes it necessary to re-validate the@requires
post-merge to prevent a few corner cases from silently merging but failing later, and that added validation is part of that first commit too (with ample comments).The 2nd commit of this PR is new validation to ensure that we reject the use of aliases in the
fields
argument of@requires
,@provides
and@key
, and this is because this change made me realised that alias were not rejected but were not working properly (they would silently make a@provides
not work for instance if used). This validation is really more of an oversight and make sense regardless of the rest of this PR, but I think it make sense to include it here because "fields with arguments" is probably the main reason why someone might to use aliases in the first place, and so this ticket makes it more important to be clear that those are not supported. To be clear, we could later add proper support for aliases, but this is probably somewhat involved and, afaict, has never be requested by any user, so not too urgent.