Make sure arguments are preserved after redirects #142
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 resolves #137 and remakes #138.
Summary:
When suggesting arguments after a redirect, calling
CommandContext#getArgument
on the given context can only access arguments declared before the redirect.When executing a command after a redirect, calling
CommandContext#getArgument
on the given context can only access arguments declared after the redirect.These two situations seem to handle arguments differently. This seems like it might be a bug, so I created #137 focusing on the problem with executing commands. It's possible this is intended behavior, but I couldn't find any documentation stating this either way. No one has confirmed or denied #137 yet, so I'm assuming this is a bug.
Without this PR, this example test for command dispatch fails:
Specifically, the exception
java.lang.IllegalArgumentException: No such argument 'number' exists on this command
is thrown when evaluating the second assertion. When parsing"base high 15 ending"
, aCommandContext
something like the following is created:When the command is executed, it uses the last child. This child does not know about the
number
argument, hence theIllegalArgumentException
.This PR makes it so that when parsing nodes redirects, the arguments from the parent
CommandContext
are copied to the child. That means parsing"base high 15 ending"
gives the following context:So, when the last child is used to execute the command, it now knows about the
number
argument, and the executor works as expected.I also thought it was weird that this example test for suggestions failed:
When creating suggestions for
"command <first> <second>"
,<second>
is supposed to get the suggestion of<first>+1
. This works if you just input"command <first> "
, so the first test passes. However, after a redirect, it doesn't work. In the second test, I'd expect that"redirect command 1 "
suggests"2"
. However, the exceptionjava.lang.IllegalArgumentException: No such argument 'number' exists on this command
is thrown instead. TheCommandContext
for this would look something like this:When creating the suggestions, this whole context is used. So, just calling
CommandContext#getArgument
, thefirst
argument can not be found since the parent context does not have any arguments.I thought this might be a bug. It makes more sense that the context representing the range that is currently being suggested should be used to get the suggestions. Here, that would mean using the
child
CommandContext
, which does have thefirst
argument.However, this modified test does pass:
Instead of using the given
CommandContext
directly, theSuggestionsProvider
callsCommandContext#getLastChild()
. I think this makes sense. The part of the command being suggested should always be the last part of the command, and hence the last child of theCommandContext
. This makes my test pass, so I guess it's okay?Not sure. If my assumption that the suggestions are only created at the end of the command is wrong, please correct me. In that case, I think it should be easy enough to change the suggestions code so that it choose the child
CommandContext
for the node that is currently being suggested.