Fixes #2589: type redeclarations cause spurious warnings

[ambv]

This addresses the problem by refusing to re-bind the explicit type for a name once one type was already present. This means it changes the logic from "last type declaration wins" to "first type declaration wins". The error about redeclaring the type is still being reported but the type does not change, which changes the errors given, producing less surprising results.

Test plan: added a new test case to unit/semanal. Without the change, there's spurious errors about names not conforming to the type defined last. With the change, only the "Name already defined" errors remain.

[JukkaL]

Looks good -- thanks for the fix!

[ddfisher]

This change prevents an "incompatible types in assignment" error from being generated on lines with a "Name already defined" errors. E.g.:

x = 0 # type: int
x = "" # type: str

now gives only the error:

test.py:2: error: Name 'x' already defined

whereas previously it would also give:

test.py:2:error: Incompatible types in assignment (expression has type "str", variable has type "int")

I think we want that error, so this should perhaps be fixed in a slightly different place.

[ambv]

In the previous case, it was the first line that would emit the error:

/tmp/qwe.py:1: error: Incompatible types in assignment (expression has type "int", variable has type "str")
/tmp/qwe.py:2: error: Name 'x' already defined

This is confusing and the point of this pull request. With the fix, there is an error being emitted only on line 2:

/tmp/qwe.py:2: error: Name 'x' already defined

Removing the second type comment will emit your original error:

/tmp/qwe.py:2: error: Incompatible types in assignment (expression has type "str", variable has type "int")

In other words, no information is lost but there's no confusing error being emitted on a line that preceeds the problem.

[ddfisher]

Oh, you're right! Sorry, I didn't read the output carefully enough.

This is strictly an improvement, then. Thanks! 👍