Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this a bug in parse_stmtseq? #10693

Closed
p5pRT opened this issue Oct 5, 2010 · 13 comments
Closed

Is this a bug in parse_stmtseq? #10693

p5pRT opened this issue Oct 5, 2010 · 13 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Oct 5, 2010

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

Searchable as RT78222$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 5, 2010

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 5, 2010

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 5, 2010

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 11, 2010

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 11, 2010

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 14, 2010

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 15, 2010

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 21, 2010

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 21, 2010

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 21, 2010

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.