[antlr-interest] BUG? - Antlr hoists unhoistable predicates

[Benjamin Niemann]

Good evening,

Austin Hastings wrote:
> Johannes Luber wrote:
>> Austin Hastings wrote:
>>   
>>> Unfortunately, Antlr3 hoisted the predicate out of the rule. This
>>> doesn't work, obviously, because the $permitFunctionSpec is a parameter
>>> to the rule (which the predicate was hoisted out of...).
>>>
>>> In cases like this, Antlr needs to catch the impossibility (detecting
>>> the use of a rule- or token- field seems a good start) and either not
>>> hoist, or construct a synthetic predicate with the correct values.
>>
>> This isn't a bug, but a design decision. Instead using a parameter use
>> either a field of the class or - recommended - use a dynamic scope
>> instead.
>>
> I won't contest that various aspects of hoisting are design decisions.
> But the simple fact is that legitimate input syntax in the grammar file
> is compiled, with no warnings or error messages, into faulty output
> code. That's a bug.
> 
> If it's hard or impossible to internally suppress hoisting predicates
> when they reference local context, that's fine - emit a diagnostic
> message telling me that I'm making a mistake. I'll happily accept a
> message telling me "you can't do that" instead of chasing around the
> generated code in a java debugger trying to understand why my grammar
> stopped working.

Unfortunately this bug is very hard to catch, because the contents of {..}?
is code in the target language (after replacing $thingies), which is an
opaque blob of character for the (target agnostic) tool.
ANTLR might complain about suspicious $... replacements in hoistable
predicates, but that covers only a part of the possible bugs.
IMHO the approach that code in actions should be debugged using target
specific tools is a good trade off to keep the complexity of ANTLR at a
reasonable level.