How change rule precedence in bison?

Question

I have two rules in which first one take precedence over the last one and parser fail to parse my expression e.g ABC.DEF its expecting SQL_TOKE_GETCLASSID there. Instead what i want is the second rule to kick in. These rule have same ancestor and have same left prefix i.e. SQL_TOKE_NAME '.'

Is there is a way to tell bison to give priority to second rule instead of first one.

First Rule

 ecclassid_fct_spec:
    SQL_TOKEN_NAME '.' SQL_TOKEN_GETECCLASSID '(' ')'
    {
     ...
    };

Second Rule

property_path:
        property_path_entry
        {
            $$ = SQL_NEW_DOTLISTRULE;
            $$->append ($1);
        }
    |   property_path '.' property_path_entry %prec '.'
        {
            $1->append($3);
            $$ = $1;
        }
    ;   

property_path_entry:
        SQL_TOKEN_NAME opt_column_array_idx
        {... }
    ;

Answer 1

What do you mean by "give priority to"? If you want to match the second rule only if it matches completely, and if not try to match the first rule, bison doesn't work that way. Bison is an LALR(1) parser, so it looks at each token and decides which set of rule prefixes that matches against, keeping track via a state machine. When it matches to the end of a rule, it reduces that rule, unless there's a longer rule that could match, in which case you get a shift/reduce conflict. In that case, you can force it choose the shift or the reduce with precedence rules, but doing so throws away the choice associated with the other possibility, and if it turns out the choice was wrong with respect to later input, there's no way to go back.

With your grammar (fragment) it needs to make the choice (it gets a shift/reduce conflict) after seeing an input of SQL_TOKEN_NAME with a lookahead of '.'. At that point it needs to know if it should treat this as a property_path_entry or the beginning of a ecclass_id_fct_spec. But which is correct depends on what is AFTER the '.', and since bison only does a single token of lookahead, it's too soon to make that choice.

Now there is a way to make bison use a more powerful parsing mechanism, that CAN do more lookahead. You can use the %glr-parser option to create a GLR parser instead of an LALR(1) parser. That may be enough by itself to make your grammar work, as long as it is not ambiguous. But if your grammar contains any ambiguities, you'll get a run-time failure, unless you add the necessary ambiguity resolving annoations to your grammar. The bison manual contains extensive documentation of GLR mode, so you should read that before attempting to use it.

Answer 2

The fragment is too small to say anything. However:

1. You may redefine ecclassid_fct_spec. Also, to help reductions you may define a new node. tmp_node:

   SQL_TOKEN_GETECCLASSID '(' ')';

2. I handled the "." issues by using the states in flex.

3. Not sure if it is possible to break SQL_TOKEN_NAME. Looks like this is generalizing.