Closed bverhoeve closed 9 months ago
@bverhoeve Check the logs and see what is being reported. Output > Mypy Type Checker is where you can see it. If you see it is using dmypy
then it might be this bug in dmypy
(https://github.com/python/mypy/issues/15677) in that case try using mypy-type-checker.preferDaemon
to false
.
If something is reported by mypy
in the logs and is not picked up by the Problems view let us know.
I've fixed the issues in the meantime, I'll see if I can reproduce the problem. The output is from a closed source codebase though so I'll have to see what I can share.
Try using mypy
instead of dmypy
, in case that is what is causing the problem. All I need to see is the pattern of the error reported, you can replace the message part with any text. What I am looking for is something like <file path>:#:#:#:#: <message>
.
This was the type error that was not shown in problems:
<path_to_file>.py:80: error: Invalid type: try using Literal[True] instead? [valid-type]
We're using local mypy
btw, not the shipped version so the daemon is not used afaik.
@bverhoeve Please try the pre-release version of the extension. This is actually a bug in mypy
(https://github.com/python/mypy/issues/15463), but we have also added a fallback for these cases. The issue here is mypy
does not repro a column number for the error.
Related https://github.com/microsoft/vscode-mypy/issues/35 Related https://github.com/microsoft/vscode-mypy/issues/156
Okay, good to know! Thanks for investigating 🙏
@karthiknadig out of curiosity I also tried this with dmypy
and then it indeed does not work. Are there plans to support this or should we use the pre-release version? We have a rather large codebase making mypy
quite slow. I tried it in the pre-release version and then the errors show correctly, although not all of the time. Are there things we should take into account when using the pre-release version?
@bverhoeve This repo is for the VS Code extension, all we do in this extension is wrap the mypy
and dmypy
tools. The bugs you see with dmypy
are also something that should be addressed in the mypy
repo. dmypy
has known issues with caching that can sometimes cause it to skip showing issues.
All we do in this extension is run mypy
/dmypy
on your behalf. The fix we did for issue with missing column number in the extension is only for the part that parses the output from mypy
/dmypy
. We will publish stable extension after some weeks of testing pre-release.
The typing issues do show up in the mypy
output tab when using dmypy
, they're just not showing up in the Problems tab, so likely a similar issue with the parsing? Apologies I could've been more clear, I meant the error formatting showing up in the Problems tab as that's our main use of the extension during development.
Can you share some of the output? I want to make sure that this is getting parsed correctly.
Hi @karthiknadig, this is some sample output:
2024-03-05 17:06:27.042 [info] [Trace - 17:06:27] Received notification 'window/logMessage'.
2024-03-05 17:06:27.042 [info] file:///path-to-file.py :
/path-to-file.py:66:1:66:22: error: Need type annotation for "VARIABLE" (hint: "VARIABLE: Optional[<type>] = ...") [var-annotated]
/path-to-file.py:87:28:87:118: error: Incompatible types in assignment (expression has type "Union[Any, None, tuple[Optional[Any], list[XMLSchemaValidationError]]]", variable has type "tuple[Any, ...]") [assignment]
/path-to-file.py:176:45:176:55: error: Argument 1 to "etree_tostring" has incompatible type "Union[Any, tuple[Any, list[XMLSchemaValidationError]]]"; expected "ElementProtocol" [arg-type]
/path-to-file.py:177:16:177:30: error: Item "bytes" of "Union[str, bytes]" has no attribute "encode" [union-attr]
/path-to-file.py:74:46:74:94: error: Argument 1 to "XMLSchema10" has incompatible type "list[str]"; expected "Union[Union[str, bytes, Path, IO[str], IO[bytes], XMLResource, Element, ElementTree], list[Union[str, bytes, Path, IO[str], IO[bytes], XMLResource, Element, ElementTree]]]" [arg-type]
/path-to-file.py:74:46:74:94: note: "List" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
/path-to-file.py:74:46:74:94: note: Consider using "Sequence" instead, which is covariant
/path-to-file.py:77:33:77:43: error: Argument 1 to "loads" has incompatible type "Union[XMLSchemaValidationError, str, None]"; expected "Union[str, bytes, bytearray]" [arg-type]
/path-to-file.py:276:16:276:86: error: Item "bytes" of "Union[str, bytes]" has no attribute "encode" [union-attr]
/path-to-file.py:276:41:276:51: error: Argument 1 to "etree_tostring" has incompatible type "Union[Any, tuple[Any, list[XMLSchemaValidationError]]]"; expected "ElementProtocol" [arg-type]
@karthiknadig were you able to check the output?
@bverhoeve These are all parsed by the pre-release version of mypy extension. Was there one you could not see in the problems window.
I'll check with the pre-release :)
There are more outputs that cannot be parsed...
2024-04-23 19:29:11.114 [info] file:///path-to-file.py:
/path-to-file.py:176:47:176:80: error: Cannot determine type of "XXX" [has-type]
/path-to-file.py:143:47:143:80: error: Cannot determine type of "XXX" [has-type]
Hi, we are using the mypy type checker plugin as the old Python plugin no longer works with newer versions of VSCode. We're noticing that quite a few problems reported by mypy are not being captured in the integrated problems window. When I check the mypy Output window, there are a lot of issues reported, also when running via the CLI. These do not show up in the problem output.
Trivial typing issues such as
a: int = 'a string'
get parsed correctly and show up in the problems window. We are using mypy version 1.7.1.I'd expect all errors to be reported in the problems window.