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

[Austin Hastings]

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.

=Austin


Johannes Luber wrote:
> Austin Hastings wrote:
>   
>> I was trying to slim down my grammar a bit by combining some rules into
>> a single parameterized rule.
>>
>> decl_specifiers[Boolean permitStorageClass, Boolean permitFunctionSpec]
>>    : ( accs+=decl_access_qualifier
>>      | type+=decl_type_spec
>>      | stcl+=decl_storage_class
>>      | {$permitFunctionSpec}? func+=decl_function_spec
>>          )+
>>    /* blah blah blah */
>>
>> This would have eliminated several nearly-identical variants.
>>
>> 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.
>>
>> =Austin
>>     
>
> 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.
>
> Best regards,
> Johannes Luber
>
>
>