Useless test in parser.yy

[David Kastrup]

parser.yy contains the following code:

music_function_identifier_musicless_prefix: MUSIC_FUNCTION {
                SCM sig = scm_object_property (yylval.scm, ly_symbol2scm 
("music-function-signature"));
                if (scm_is_pair (sig) && to_boolean (scm_memq (ly_music_p_proc, 
scm_cdr (scm_reverse (sig)))))
                {
                        PARSER->parser_error (@$, "Music function applied to 
event may not have a Music argument, except as the last argument.");
                }
        }
        ;

This error check can never trigger since
music_function_identifier_musicless_prefix is used only in grammar rules
where the function signature meets the restraints: it is nonsensical to
check for the presence of a shift-reduce conflict at runtime when one
has eliminated the conflict from the rule set already.

If one uses the following code:

zap=#(define-music-function (parser location one two) (ly:music? ly:music?)
      #{ #} )
{ c-\zap c c-2 }

which is exactly the scenario that is supposed to be caught, the
resulting error message is

lilypond /tmp/junk.ly
GNU LilyPond 2.15.6
Processing `/tmp/junk.ly'
Parsing...
/tmp/junk.ly:3:9: error: syntax error, unexpected EXPECT_MUSIC
{ c-\zap 
         c c-2 }
/tmp/junk.ly:3:0: error: errors found, ignoring music expression

{ c-\zap c c-2 }

One would need a rule including the "error" symbol and a generic music
expression as a fallback, avoiding the shift-reduce conflict.  Since the
rule would trigger only in the case of an error and an available
non-unique music expression, the condition would not require checking,
being reasonably clear.

Fixing this is a low priority (it went unnoticed so far and only
concerns the legibility of the error message and recovery).  I intend
working in that area anyway and would likely relax the requirements in a
manner that only prescribes using grouped music in a limited number of
contexts.

-- 
David Kastrup