Fix warning for nested arrays with custom types #11
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.
I've been encountering warnings such as:
@param tag has unknown parameter name: ]
or@param tag has unknown parameter name: ,
I noticed that this only occurs with signatures that contain nested custom types such as
T::Array[Custom[String]]
.After debugging I noticed that the inner node
Custom[String]
is actually parsed asCustom[String]]
within Yard parser.So while converting
T::Array[Custom[String]]
node we correctly convert the outerT::Array
and callconvert
with its children, the innerCustom[String]]
node. Then we enter theelse
branch of the:aref
case and returnCustom[String]]
which results in the warning.I noticed that the parser returns an extra
]
even forT::Array[String]
signature. This case is not outputting a warning because we extract the relevant information here.I wasn't 100% sure how to fix this so I'm open to suggestions. Currently I opted for a similar approach as the
T::Array
case. As you can see from the test cases for an input ofT::Array[Custom[String]]
we would outputArray<Custom[String]>
.This could be wrong if we encountered "non array" signatures inside that
else
block. I'm curious if that is a possibility given we are in a:aref
node