Skip to content

Implicit for..in comprehension conflicts with the following in keyword on the same depth. #923

Description

@pepkin88

The implicit version of for..in comprehension (the version without the in keyword) causes compilation error on line, where the in keyword is used, and is on the same depth. And by depth I don't mean indent, it is something different, something internal.

Minimal example:

[1 for a]
[b in c]

Extended example, with diverse ways of increasing the depth:

[[{b: {[.., 1] for a}}]]
->
  if c
    d
      .e (.f in [2 3])

I noticed, that only comprehensions are affected by this bug, and only those without the in keyword.
The construction for a => .. doesn't cause an error.

The in expression also has to be somehow wrapped. This:

[1 for a]
->
  b in c

is not erroneous.

Activity

  1. added a commit that references this issue on Sep 23, 2016
  2. rhendric commented on Sep 23, 2016

    @rhendric
    Collaborator

    It's always fun when you see a new issue and you know exactly what instruction must be missing to produce that effect. 😄 Nice catch.

  3. added a commit that references this issue on Sep 27, 2016
  4. summivox commented on Oct 25, 2016

    @summivox
    Contributor

    @rhendric : before I stopped working on this, I was planning a migration of loophead handling to parser stage (instead of current lexer hacks)... Anyway good job figuring out the lexer fix!

  5. rhendric commented on Oct 25, 2016

    @rhendric
    Collaborator

    Oh, @gkz or @pepkin88 : #925 merged, so one of you can close this—I screwed up the GitHub autoclose majyyks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions