hrw4u: grammar accepts bare operator statements (`no-op;`) that can never compile

Open Beginner friendly

#13,701 opened on Sep 17, 2026 0 comments 0 reactions 1 assignee View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 1/5
Estimated time: Under an hour
Newbie friendliness: 88/100

Issue type: Bug
Clarity: Clearly specified
Activity status: Active
Domain: compilers

Research direction

Start at tools/hrw4u/grammar/hrw4u.g4 around line 171 and compare the bare-operator alternative with the documented call form and separate break alternative. Remove the unreachable bare form, then check the tests/data corpus and confirm call-form operators still work while bare operators produce a syntax error.

Written by the indexing model from the issue text.

Description

hrw4u

Summary

The grammar has a statement alternative for a bare operator without parentheses:
https://github.com/apache/trafficserver/blob/13ef6a7618bda4c36835aab291de95d02e86f2ed/tools/hrw4u/grammar/hrw4u.g4#L171

Nothing written that way compiles. Every op is rejected, so the alternative is
unreachable and should be removed from the grammar.

Reproduce

source	result
`no-op();`	`no-op`
`no-op;`	`error: This operator requires an argument`
`skip-remap;`, `set-debug;`	same error

Why remove rather than fix

The call form is the only form anything produces or documents:

producer	form
`doc/admin-guide/configuration/hrw4u.en.rst`	`no-op();`, `set-debug()`, `skip-remap()`
reverse conversion, u4wrh (`src/hrw_symbols.py:315`)	always `name()`
test corpus (`tests/data`)	`no-op();`, 0 bare-op inputs

Making the bare form work instead (check arity rather than validator presence)
would add a second spelling for the same statement with no caller asking for
it. break; is a separate alternative and is unaffected either way.

Trade-off: after removal, no-op; becomes an ANTLR syntax error rather than a
named one. If the friendlier message matters, it belongs in the suggestion
engine, not in a grammar alternative that produces no output.

Note

test_the_corpus_reaches_every_grammar_rule does not catch this: it records
rule names, and statement is reached through its other alternatives.

Dominant language: C++
Stars: 2k
Forks: 877
Avg merge: 4d 18h
Merged PRs (30d): 52

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

[Bug] NULL pointer dereference in llm_running_callback (NGZA-AX-LLM #3) Open

Difficulty 1/5 Under an hour Newbie friendliness 90/100

AXERA-TECH/ax-llm#77 · Opened Sep 22, 2026
resume() sends a second HTTP response (400) after a successful resume Open

Difficulty 1/5 Under an hour Newbie friendliness 90/100

games-on-whales/wolf#509 · Opened Sep 21, 2026
pn7160: reader goes permanently deaf — post-read IRQ-low check fails reads that succeeded Open

Difficulty 2/5 1-3 hours Newbie friendliness 74/100

esphome/esphome#19452 · Opened Sep 21, 2026
Eval bug: Ministral-3 tool-calls during reasoning are not processed Open

bug-unconfirmed

Difficulty 2/5 1-3 hours Newbie friendliness 76/100

ggml-org/llama.cpp#29248 · Opened Sep 21, 2026
run_tests.py fails on windows, but running tests individually works Open

Difficulty 2/5 1-3 hours Newbie friendliness 74/100

NVIDIA/cuda-samples#453 · Opened Sep 21, 2026

More C++ issues