refactor(filter): Builtin field arguments grammar #425
Conversation
This file contains hidden or 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
The parser got the ability to produce field literals with optional arguments. New bare bound variable and segment bound variable literals are added for a cleaner and more accurate representation of bare bounded variables, bound segments and bound fields respectively.
Most functions now support bare and segment bound argument types.
Rework the value accessors to operate with the new field type that encapsulates the field argument. Additionally, bound segments are propagated to all accessors and currently used in the PE accessor to determine if the section entropy needs to be calculated.
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.
What is the purpose of this PR / why it is needed?
This changeset brings a significant refactoring in the field arguments area. Previously, the field arguments were parsed on the fly, when extracting the value in the accessor. A regular expression-based approach would decide if the field could have an argument.
This was undermining the correctness of the rule grammar.
The parser is now extended to support field literals with arguments. Arguments can be optional or required. When provided the argument value must conform to the allowed pattern. All this information is stored within the field information and utilized in the
parser to produce the field literal or return an error, when, for example, a field with a required argument is not given.
As a side effect of this refactoring, new literals are introduced to better convey different rule language elements: bare bound variable and bound segment literals.
Finally, all accessors are reworked to adapt to the new field structure. The end result is a more efficient, cleaner, and concise code base.
Some examples:
Is semantically incorrect because the
kevt.argfield requires an argument.Both expressions are correct.
ps.envsaccepts an optional argument (environment variable name), but if not given all env variables are returned as a string slice.What type of change does this PR introduce?
/kind refactor (non-breaking change that restructures the code, while not changing the original functionality)
/kind cleanup
Any specific area of the project related to this PR?
/area rule-engine
/area filters