Is this a bug in parse_stmtseq?

[p5pRT]

Migrated from rt.perl.org#78222 (status was 'resolved')

Searchable as RT78222$

[p5pRT]

From ben@morrow.me.uk

I'm not sure if this is a bug or if I;m doing something wrong, but I
can't seem to get parse_stmtseq to work properly at the top level of the
program. What I'm trying to do is parse expressions of the form

  ENTER { 1; }

with this keyword plugin function​:
 
  static int
  my_keyplug(pTHX_ char *ptr, STRLEN len, OP **ops)
  {
  OP *blk;

  if (len == 5 && (strnEQ(ptr, "ENTER", len))) {

  lex_read_space(0);
  if (lex_read_unichar(0) != '{')
  Perl_croak(aTHX_ "Need a block");

  blk = parse_stmtseq(0);

  if (lex_read_unichar(0) != '}') {
  op_free(blk);
  Perl_croak(aTHX_ "Missing right curly bracket");
  }

  Perl_warn(aTHX_ "Got an ENTER");
  /* do something useful with blk */

  *ops = newOP(OP_NULL, 0);
  return KEYWORD_PLUGIN_STMT;
  }
  return old_keyplug(aTHX_ ptr, len, ops);
  }

What I'm seeing is that the swallow-the-trailing-} logic doesn't work
properly if the ENTER{} is at the top level​:

  ~/src/perl/Perl6-Blocks% perl -Mblib -MPerl6​::Blocks -e'ENTER { 1; }'
  Got an ENTER at -e line 1.
  Unmatched right curly bracket at -e line 1, at end of line
  Missing right curly or square bracket at -e line 1, at end of line
  Execution of -e aborted due to compilation errors.

  ~/src/perl/Perl6-Blocks% perl -Mblib -MPerl6​::Blocks -e'{ ENTER { 1; } }'
  Got an ENTER at -e line 1.

It doesn't seem to matter what type of block (do, sub, loop, ...) the
ENTER is surrounded with, and it doesn't matter if there are more
expressions between the ENTER{} and the end of the surrounding block, as
long as the block is there.

Is this a bug, or am I doing something wrong?

Ben

[p5pRT]

From zefram@fysh.org

Ben Morrow wrote​:

Unmatched right curly bracket at -e line 1, at end of line
Missing right curly or square bracket at -e line 1, at end of line
...
Is this a bug,

Quite possibly. I've been thinking about the bracket handling quite a
bit in the past few days. The lexer's bracket stack is a complication
that I didn't properly account for in parse_stmtseq()​: it is, of course,
not designed to work with recursive-descent parsing. I can imagine a
few situations in which it's likely to go wrong, though I haven't tried
them out yet.

I have a plan to fix it, essentially by adding a catch-all pseudo-bracket
onto tthe stack when entering a recursive-descent level. I'm definitely
going to want this in place before I move on to parse_expr(). I'll look
more closely at your problem case when I work on it. Thanks for the
report.

-zefram

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From ben@morrow.me.uk

Quoth zefram@​fysh.org (Zefram)​:

Ben Morrow wrote​:

Unmatched right curly bracket at -e line 1, at end of line
Missing right curly or square bracket at -e line 1, at end of line
...
Is this a bug,

Quite possibly. I've been thinking about the bracket handling quite a
bit in the past few days. The lexer's bracket stack is a complication
that I didn't properly account for in parse_stmtseq()​: it is, of course,
not designed to work with recursive-descent parsing. I can imagine a
few situations in which it's likely to go wrong, though I haven't tried
them out yet.

I don't know if you've got some Cunning Plan here, but this fixes the
obvious problem (and a few others) in the obvious way. If we don't use
this, block_start and block_end will need exporting, at least.

Ben

[p5pRT]

From ben@morrow.me.uk

0001-Add-parse_block-which-parses-a-complete-Perl-block.patch

[p5pRT]

From zefram@fysh.org

Ben Morrow wrote​:

I don't know if you've got some Cunning Plan here, but this fixes the
obvious problem (and a few others) in the obvious way.

It does not actually fix the problem with parse_stmtseq.

this, block_start and block_end will need exporting, at least.

Yes, that's on my agenda too. Plain parse_block is inadequate for a lot
of obvious syntax extensions involving blocks​: many need to insert some
processing between the block_start and the statements contained within
the block.

Note​: I have not properly reviewed the parse_block patch.

-zefram

[p5pRT]

From zefram@fysh.org

I wrote​:

I have a plan to fix it, essentially by adding a catch-all pseudo-bracket
onto tthe stack when entering a recursive-descent level. I'm definitely
going to want this in place before I move on to parse_expr().

Attached patch implements this.

-zefram

[p5pRT]

From zefram@fysh.org

0001-handle-bracket-stack-better-in-recdescent-parsing.patch

[p5pRT]

From zefram@fysh.org

Ben Morrow wrote​:

Subject​: [PATCH] Add parse_block, which parses a complete Perl block.

Attached is my version of parse_block(). The core of it is the same
as Ben's version. This version has documentation and more tests, and
I've taken the middle layer in toke.c in a slightly different direction.
This depends on my recent patches relating to recursive-descent parsing.

-zefram

[p5pRT]

From zefram@fysh.org

0001-function-to-parse-Perl-code-block.patch

[p5pRT]

From @cpansprout

On Wed Oct 13 18​:08​:12 2010, zefram@​fysh.org wrote​:

I wrote​:

I have a plan to fix it, essentially by adding a catch-all pseudo-bracket
onto tthe stack when entering a recursive-descent level. I'm definitely
going to want this in place before I move on to parse_expr().

Attached patch implements this.

-zefram

Thank you. Applied as a7aaec6.

[p5pRT]

From @cpansprout

On Fri Oct 15 05​:18​:52 2010, zefram@​fysh.org wrote​:

Ben Morrow wrote​:

Subject​: [PATCH] Add parse_block, which parses a complete Perl block.

Attached is my version of parse_block().

Thank you. Applied as e53d8f7.

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'