Robot capture keyword started from varref #1571
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If {exclusive} flag is specified and an input line matches a regex
pattern, the input line is consumed always; lregex skips the rest of
patterns for the input line. This is the original behavior of lregex
engine.
This commit extends the behavior if a pattern is specified with
matchCallbackPattern function. Even if a regex pattern (with
{exclusive}) matches an input line, and a callback false returns
false, the input line is never consumed. The callback function must
return true for consuming the input line.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
|
Oputput -> Output |
Input:
*** Keywords ***
${embedded arg} Starting Single
No Operation
Output:
${embedded arg} Starting Single input.robot /^${embedded arg} Starting Single$/;" k
Close universal-ctags#1570.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
masatake
force-pushed
the
robot--capture-keyword-started-from-varref
branch
from
cd8b62d
to
0e230a1
Compare
|
@k-takata, thank you. Updated. |
masatake
force-pushed
the
robot--capture-keyword-started-from-varref
branch
from
1019889
to
50b0604
Compare
masatake
force-pushed
the
robot--capture-keyword-started-from-varref
branch
from
50b0604
to
70a6c34
Compare
|
Regex engine on MacOSX doesn't accept the updated regex pattern. I will inspect the pattern. |
|
make chop LANGUAGES=Robot is passed. |
|
I'm afraid that this parser enters infinite loop. I would like to implement "kick" target before merging this. |
|
I named "slap" instead of "kick". |
derekschrock
added a commit
to derekschrock/ctags
that referenced
this pull request
Sep 5, 2018
Running unit tests tmain and units via 'make check' the empty expression
.{0} from the matching group in parsers/robot.c was causing FreeBSD libc
regcomp to produce an error: empty (sub)expression.
tmain would fail for some checks while units would fail for robots checks.
Removing the emptry expression .{0} "match anything exactly zero times"
fixes this issue and all expected tests pass for both tmain and units.
Testing the same change, removing the expression .{0} from the
matching group, on centos7 does not appear to have any regessions.
This reverts the following commit
universal-ctags@81a4593
That was created for the following issue:
universal-ctags#1571 (comment)
It's possible there's some regression for macOS however macOS on Travis
doesn't seem to have any issues.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Input:
Output:
Close #1570.
Close #1572.