This still looks like a hack. Why the parser even puts a semicolon into the sp_proc_stmt ?

Hi,
when debuged noted that trigger_tail is invoked which is calling sp_proc_stmt.
However, I don't see the rule sp_proc_stmt using ";", but sp_proc_stmts and sp_proc_stmts1:

sp_proc_stmt:

          sp_proc_stmt_in_returns_clause

        | sp_proc_stmt_statement

        | sp_proc_stmt_leave

        | sp_proc_stmt_iterate

        | sp_proc_stmt_open

        | sp_proc_stmt_fetch

        | sp_proc_stmt_close

        ;

sp_proc_stmts:

          /* Empty */ {}

        | sp_proc_stmts  sp_proc_stmt ';'

        ;

sp_proc_stmts1:

          sp_proc_stmt ';' {}

        | sp_proc_stmts1  sp_proc_stmt ';'

        ;

sp_proc_stmts is used in

• sp_block_content which is used in sp_labeled_block

sp_proc_stmts1 is used in

• sp_if
• sp_elseifs
• simple_when_clause
• searched_when_clause
• else_clause_opt
• loop_body
• while_body
• repeat_body

None of above rules are used in trigger_tail (used in test case).
Above changes introduced with commit from 2004 e324c0cc8407bcbde70d4386ddf26c78ca6443b2fafb254d49da77ec3e0ff3be

Hi serg, holyfoot,
related to the above question:
parser puts the semicolon because it (;) is pre-processed in the lex (MY_LEX_SEMICOLON -> MY_LEX_CHAR and token (not 0) is returned).
In the grammar it acts as a lookahead token (so yyChar != YYEMPTY will be called for generating the instruction for the sp. It doesn't have any effect to change anything there.
In the next iteration single ; is processed as no_lookahead token and after that rest of the statements.
Rawbuffer for multistatements is for example in this form $34 = 0x7fffd8013780 "CREATE EVENT td.foo1\nON SCHEDULE EVERY 1 DAY\nDO\nDELETE FROM Token WHERE DATE(time_end) < CURRENT_DATE;\nSELECT 1
ev_sql_stmt: will set the body of sp to the pre-processed lex m_cpp_ptr via get_cpp_ptr() and will look like \nDELETE FROM Token WHERE DATE(time_end) < CURRENT_DATE;.
I have tried multiple things and found related commits, but couldn't find a way to remove ; from m_cpp_ptr as this is the only thing what could be done before grammar.
In grammar only thing that can be done is via set_stmt_end() and that function is also relaying on the pre-processed statement and there is already a patch to act based on the last character ; in the pre-processed stream.
However it is still not clear should the parsing error be raised or ; be removed from m_body that is created by function set_stmt_end()?!
Since there is some work already done by holyfoot in MDEV-6421, hope I will get some review comments, thoughts and hints.

I've fixed the parser to not include the semicolon into the event definition

The patch
https://github.com/MariaDB/server/commit/7e5a3ed83f709cba67385b9faf45d1a4f1686b08
is OK to push.