===========================================================
.___ __ __
_________________ __ __ __| _/|__|/ |_
/ ___\_` __ \__ \ | | \/ __ | | \\_ __\
/ /_/ > | \// __ \| | / /_/ | | || |
\___ /|__| (____ /____/\____ | |__||__|
/_____/ \/ \/
grep rough audit - static analysis tool
v2.8 written by @Wireghoul
=================================[justanotherhacker.com]===
antlr4-4.7.2/doc/predicates.md-92-
antlr4-4.7.2/doc/predicates.md:93:A predicate that depends on a parameter or local variable of the surrounding rule, is considered a context-dependent predicate. Clearly, we can only evaluate such predicates within the rules in which they're defined. For example, it makes no sense for the decision in prog below to test context-dependent predicate `{$i<=5}?`. That `$i` local variable is not even defined in `prog`.
antlr4-4.7.2/doc/predicates.md-94-
##############################################
antlr4-4.7.2/doc/predicates.md-117-
antlr4-4.7.2/doc/predicates.md:118:The prediction process is trying to figure out what can follow an if statement other than an else clause. Since the input can have multiple stats in a row, the prediction for the optional branch of the else subrule reenters stat. This time, of course, it gets a new copy of `$i` with a value of 0, not 5. ANTLR ignores context-dependent predicate `{$i==0}?` because it knows that the parser isn't in the original stat call. The predicate would test a different version of `$i` so the parser can't evaluate it.
antlr4-4.7.2/doc/predicates.md-119-
##############################################
antlr4-4.7.2/doc/tree-matching.md-52-
antlr4-4.7.2/doc/tree-matching.md:53:This would allow pattern `<<ID>> = <<expr>> ;$<< ick $>>` to be interpreted as elements: `ID`, ` = `, `expr`, and ` ;<< ick >>`.
antlr4-4.7.2/doc/tree-matching.md-54-
##############################################
antlr4-4.7.2/doc/actions.md-23-
antlr4-4.7.2/doc/actions.md:24:All tokens have a collection of predefined, read-only attributes. The attributes include useful token properties such as the token type and text matched for a token. Actions can access these attributes via `$label.attribute` where label labels a particular instance of a token reference (`a` and `b` in the example below are used in the action code as `$a` and `$b`). Often, a particular token is only referenced once in the rule, in which case the token name itself can be used unambiguously in the action code (token `INT` can be used as `$INT` in the action). The following example illustrates token attribute expression syntax:
antlr4-4.7.2/doc/actions.md-25-
##############################################
antlr4-4.7.2/doc/actions.md-34-
antlr4-4.7.2/doc/actions.md:35:Because there are two references to the `FLOAT` token, a reference to `$FLOAT` in an action is not unique; you must use labels to specify which token reference you’re interested in.
antlr4-4.7.2/doc/actions.md-36-
antlr4-4.7.2/doc/actions.md:37:Token references within different alternatives are unique because only one of them can be matched for any invocation of the rule. For example, in the following rule, actions in both alternatives can reference `$ID` directly without using a label:
antlr4-4.7.2/doc/actions.md-38-
##############################################
antlr4-4.7.2/doc/actions.md-59-
antlr4-4.7.2/doc/actions.md:60:`$T` and `$L` evaluate to `Token` objects for token name `T` and token label `L`. `$ll` evaluates to `List<Token>` for list label `ll`. `$T.attr` evaluates to the type and value specified in the following table for attribute `attr`:
antlr4-4.7.2/doc/actions.md-61-
##############################################
antlr4-4.7.2/doc/actions.md-74-
antlr4-4.7.2/doc/actions.md:75:ANTLR predefines a number of read-only attributes associated with parser rule references that are available to actions. Actions can access rule attributes only for references that precede the action. The syntax is `$r.attr` for rule name `r` or a label assigned to a rule reference. For example, `$expr.text` returns the complete text matched by a preceding invocation of rule `expr`:
antlr4-4.7.2/doc/actions.md-76-
##############################################
antlr4-4.7.2/doc/actions.md-86-
antlr4-4.7.2/doc/actions.md:87:You can also use `$ followed by the name of the attribute to access the value associated with the currently executing rule. For example, `$start` is the starting token of the current rule.
antlr4-4.7.2/doc/actions.md-88-
##############################################
antlr4-4.7.2/doc/actions.md-92-
antlr4-4.7.2/doc/actions.md:93:`$r` and `$rl` evaluate to `ParserRuleContext` objects of type `RContext` for rule name `r` and rule label `rl`. `$rll` evaluates to `List<RContext>` for rule list label `rll`. `$r.attr` evaluates to the type and value specified in the following table for attribute `attr`:
antlr4-4.7.2/doc/actions.md-94-
##############################################
antlr4-4.7.2/doc/actions.md-96-|---------|----|-----------|
antlr4-4.7.2/doc/actions.md:97:|text|String|The text matched for a rule or the text matched from the start of the rule up until the point of the `$text` expression evaluation. Note that this includes the text for all tokens including those on hidden channels, which is what you want because usually that has all the whitespace and comments. When referring to the current rule, this attribute is available in any action including any exception actions.|
antlr4-4.7.2/doc/actions.md-98-|start|Token|The first token to be potentially matched by the rule that is on the main token channel; in other words, this attribute is never a hidden token. For rules that end up matching no tokens, this attribute points at the first token that could have been matched by this rule. When referring to the current rule, this attribute is available to any action within the rule.|
antlr4-4.7.2/doc/actions.md-99-|stop|Token|The last nonhidden channel token to be matched by the rule. When referring to the current rule, this attribute is available only to the after and finally actions.|
antlr4-4.7.2/doc/actions.md:100:|ctx|ParserRuleContext|The rule context object associated with a rule invocation. All of the other attributes are available through this attribute. For example, `$ctx.start` accesses the start field within the current rules context object. It’s the same as `$start`.|
antlr4-4.7.2/doc/actions.md-101-
##############################################
antlr4-4.7.2/doc/actions.md-120-
antlr4-4.7.2/doc/actions.md:121:It turns out that, in the grammar realm, distant rules sometimes need to communicate with each other, mostly to provide context information to rules matched below in the rule invocation chain. (Naturally, this assumes that you are using actions directly in the grammar instead of the parse-tree listener event mechanism.) ANTLR allows dynamic scoping in that actions can access attributes from invoking rules using syntax `$r::x` where `r` is a rule name and `x` is an attribute within that rule. It is up to the programmer to ensure that `r` is in fact an invoking rule of the current rule. A runtime exception occurs if `r` is not in the current call chain when you access `$r::x`.
antlr4-4.7.2/doc/actions.md-122-
##############################################
antlr4-4.7.2/doc/actions.md-203-
antlr4-4.7.2/doc/actions.md:204:Referencing `$block::symbols` accesses the `symbols` field of the most recently invoked `block`’s rule context object. If you need access to a symbols instance from a rule invocation farther up the call chain, you can walk backwards starting at the current context, `$ctx`. Use `getParent` to walk up the chain.
##############################################
antlr4-4.7.2/doc/faq/actions-preds.md-10-
antlr4-4.7.2/doc/faq/actions-preds.md:11:testing to see if that clause was matched can be done using `$EQUALS!=null` or `$expr.ctx!=null` where `$expr.ctx` points to the context or parse tree created for that reference to rule expr.
##############################################
antlr4-4.7.2/doc/parsing-binary-files.md-25-
antlr4-4.7.2/doc/parsing-binary-files.md:26:If there are actual characters like `$` or `!` encoded as bytes in the binary file, you can refer to them via literals like `'$'` as you normally would. See `'.'` in the grammar.
antlr4-4.7.2/doc/parsing-binary-files.md-27-
##############################################
antlr4-4.7.2/doc/antlr-project-testing.md-34-
antlr4-4.7.2/doc/antlr-project-testing.md:35:The grammars are strings representing StringTemplates (`ST` objects) so `<writeln("$text")>` will get replace when the unit test file is generated (`Test.java`, `Test.cs`, ...). The `writeln` template must be defined per target. Here are all of the
antlr4-4.7.2/doc/antlr-project-testing.md-36-[Target templates for runtime tests](https://github.com/antlr/antlr4/tree/master/runtime-testsuite/resources/org/antlr/v4/test/runtime/templates).
##############################################
antlr4-4.7.2/doc/lexer-rules.md-203-
antlr4-4.7.2/doc/lexer-rules.md:204:ANTLR does no special `$x` attribute translations in lexer actions (unlike v3).
antlr4-4.7.2/doc/lexer-rules.md-205-
##############################################
antlr4-4.7.2/tool-testsuite/test/org/antlr/v4/test/tool/TestActionTranslation.java-180- "e returns [int v]\n" +
antlr4-4.7.2/tool-testsuite/test/org/antlr/v4/test/tool/TestActionTranslation.java:181: " : a=e op=('*'|'/') b=e {$v = eval($a.v, $op.type, $b.v);}\n" +
antlr4-4.7.2/tool-testsuite/test/org/antlr/v4/test/tool/TestActionTranslation.java-182- " | INT {$v = $INT.int;}\n" +