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

[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.

[rhendric]

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.

[summivox]

@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!

[rhendric]

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