fast-parser py2 stops checking files when it hits misplaced type annotation

[euresti]

I noticed when checking a large project with the fast-parser that I was getting fewer errors than with the regular parser. I then noticed the last error was error: misplaced type annotation Here's a repro:

def foo():
    "Misplaced type below"
    # type: () -> None
    pass

def bar():
    # type: () -> None
    "Type placed correctly"
    blah = None
    print(blah)

bar should end up showing a type error Need type annotation for variable. But instead only misplaced type annotation is shown. If you add other files to this folder and run mypy on that folder, only the single error will still show. For example:

f2.py contains:

def bar():
    # type: () -> None
    "Type placed correctly"
    blah = None
    print(blah)

f1.py contains the above. mypy --py2 --fast-parser f1.py f2.py will only return the single error for f1.

[ddfisher]

This is similar to the current behavior for a syntax error (because to the fast parser, this is a syntax error).

How impactful do you find this issue?

[euresti]

I see. I guess in the non fast parser the line is ignored and the function
is just not typed. Or does the non fast parser also print out the error and
I missed it.

David
On Jun 4, 2016 12:25 PM, "David Fisher" [email protected] wrote:

This is similar to the current behavior for a syntax error (because to the
fast parser, this is a syntax error).

How impactful do you find this issue?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1647 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABCCApxeHxzIkE6YFEHH4zCB-cETzmyLks5qIdEUgaJpZM4IuMD4
.

[ddfisher]

The non fast parser ignores the line entirely (which is pretty undesirable, IMO).

[euresti]

Yeah. I think what confused me was the difference. It might be nice if the
error message said that checking stopped. Otherwise you think, I only have
one error, only to fix it and have more errors show up. But now that I know
why this happens I can fix them in my code. And I agree that it's better
that we know what's happening vs not getting type info.
On Jun 4, 2016 1:09 PM, "David Fisher" [email protected] wrote:

The non fast parser ignores the line entirely (which is pretty
undesirable, IMO).

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1647 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABCCApCjd15PqEB7H2NZWSAVQheHP-49ks5qIdt1gaJpZM4IuMD4
.

[gvanrossum]

I assume that adding a (note) message when the parser stops (or for all "blocker" errors) would be easy.

…

--Guido (mobile)

[ddfisher]

Yeah, that's a good idea!

[gnprice]

Also useful would be to keep going on other files, even though we can't continue on that one file.

[gvanrossum]

There's a concept of a "blocker" error. Once you've seen a blocker in a file it's not safe to continue checking other files that might depend on that file, so we then abandon the entire run. I think a parse error always counts as a blocker.

[gnprice]

Hmm, true. I'm pretty sure it would be safe to carry on as far as parsing other files, which would find more errors of the same kind, but that's probably not often enough helpful to be worth complicating the logic for.

[gnprice]

I'm actually puzzled, though, looking at the code -- it doesn't look like we set blocker=True on this error:
https://github.com/python/mypy/blob/9982db6/mypy/fastparse.py#L73

And I can't actually find any examples of blockers other than this one:
https://github.com/python/mypy/blob/9982db6/mypy/fastparse.py#L73

[ilevkivskyi]

We have two other issues to track better support for blocking errors #3850 and #5535, so this can be closed.