Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrated problems output doesn't support --show-error-end mypy option #20044

Closed
AntonVucinic opened this issue Oct 20, 2022 · 10 comments
Closed
Assignees
Labels
area-linting bug Issue identified by VS Code Team member as probable bug

Comments

@AntonVucinic
Copy link

Type: Bug

Behaviour

Expected vs. Actual

After replacing default --show-column-numbers with --show-error-end in python.linting.mypyArgs array, the whole part of the code that is causing the error should be highlighted (default setting highlights only the token at the starting position), instead errors stop apearing in the problems view and no errors are highlighted in the code.

Steps to reproduce:

  1. In empty project create a test.py file with a mypy error (e.g. x: int = 'a')
  2. Change --show-column-numbers to --show-error-end in python.linting.mypyArgs setting

Diagnostic data

  • Python version (& distribution if applicable, e.g. Anaconda): 3.10.5
  • Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Conda
  • Value of the python.languageServer setting: Default
Output for Python in the Output panel (ViewOutput, change the drop-down the upper-right of the Output panel to Python)

> ~/anaconda3/bin/conda run -n py310 --no-capture-output python ~/.vscode-server/extensions/ms-python.python-2022.16.1/pythonFiles/get_output_via_markers.py ~/.vscode-server/extensions/ms-python.python-2022.16.1/pythonFiles/linter.py -m mypy --follow-imports=silent --ignore-missing-imports --show-error-end --no-pretty ./test.py
cwd: .
##########Linting Output - mypy##########

test.py:1:10:1:12: error: Incompatible types in assignment (expression has type "str", variable has type "int")
Found 1 error in 1 file (checked 1 source file)

User Settings


languageServer: "Pylance"

linting
• mypyArgs: "<placeholder>"
• mypyEnabled: true

Extension version: 2022.16.1
VS Code version: Code 1.72.2 (d045a5eda657f4d7b676dedbfa7aab8207f8a075, 2022-10-12T22:15:18.074Z)
OS version: Windows_NT x64 10.0.22000
Modes:
Sandboxed: No
Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2
Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2

@github-actions github-actions bot added the triage-needed Needs assignment to the proper sub-team label Oct 20, 2022
@karthiknadig karthiknadig self-assigned this Oct 24, 2022
@karthiknadig karthiknadig added bug Issue identified by VS Code Team member as probable bug area-linting labels Oct 24, 2022
@karthiknadig
Copy link
Member

Currently we don't support customized output when using the problems window. We parse the output and collect details of what went wrong. So, the only arguments that are supported are the ones that don't change the output format.

If you need to use --show-error-codes, I recommend creating a task via task.json.

@karthiknadig karthiknadig added the info-needed Issue requires more information from poster label Nov 4, 2022
@AntonVucinic AntonVucinic changed the title Integrated problems output doesn't support --show-error-codes mypy option Integrated problems output doesn't support --show-error-end mypy option Nov 5, 2022
@AntonVucinic
Copy link
Author

Just realised the title was wrong. The problem isn't adding the --show-error-codes option (which parses correctly and shows in the output pannel and when hovering over the error in code) it's the --show-error-end options which replaces the default output <file>:<row>:<col>:<message> with <file>:<row>:<col>:<end-row>:<end-col>:<message>. These lines don't get correctly parsed and as a result don't show up in the output panel or get underlined in code. The current behaviour is to just underline the token at the starting location but this seems wrong to me as errors could span multiple tokens. Also this behaviour is already implemented for the pylint linter so I assume that it shouldn't be to difficult to fix it for mypy (probably just updating the parsing regex and a few more code adjustments).

@brettcannon brettcannon removed the triage-needed Needs assignment to the proper sub-team label Dec 22, 2022
@brettcannon brettcannon removed the info-needed Issue requires more information from poster label Mar 2, 2023
@trinitronx
Copy link

trinitronx commented Aug 11, 2023

Confirmed that the behavior reported in @AntonVucinic's latest comment is the case:

  • --show-error-end option set in python.linting.mypyArgs results in no Problems from mypy output being parsed correctly in the Problems window

    • Resulting output from mypy can be seen in Output -> Python window
      • mypy output format with --show-error-end has 4 numbers separated by colons: <file>:<row>:<col>:<end-row>:<end-col>:<message>
      • Problems window does not parse these at all
    • Screenshot:
      • swappy-20230810_230110
  • --show-error-end option NOT set results in mypy linter output being parsed correctly in Problems window, but only first letter of each is underlined by VSCode as "squiggles" in UI

    • First letter underlined corresponds to col from mypy linter output
    • mypy output seen in Output -> Python window follows format: <file>:<row>:<col>:<message>
    • Screenshot:
      • swappy-20230810_224208
EXPAND for platform / package version info

Version: 1.79.2
Commit: 695af097c7bd098fbf017ce3ac85e09bbc5dda06
Date: 2023-07-17T00:12:34.652Z
Electron: 22.3.18
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Linux x64 6.1.38-1-MANJARO

A/B experiments: No current experiments.
Extension Author (truncated) Version
vscode-pull-request-github Git 0.66.2
test-adapter-converter hbe 0.1.6
vscode-test-explorer hbe 2.21.1
vscode-python-test-adapter lit 0.7.1
python-path mge 0.0.14
isort ms- 2022.8.0
python ms- 2023.12.0
pytest-fixtures nic 0.3.0
vscode-xml red 0.26.1
vscode-yaml red 1.14.0
python-tox the 1.0.0
CPUs Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz (8 x 4400)
GPU Status 2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg) 2, 2, 2
Memory (System) 62.69GB (20.17GB free)
Process Argv --ozone-platform-hint=wayland --ozone-platform-hint=wayland --unity-launch
Screen Reader no
VM 0%

Expected Behavior

  • Users would probably expect the red "squiggles" to underline the entire section of the problem indicated by mypy output.
    • That is to say:
      • The default flags to mypy should probably include --show-error-end
      • The default parsed format should be: <filename>:<row>:<col>:<end-row>:<end-col>:<message>
      • VSCode UI should underline the section starting on line #<row> from <col> and ending on line #<end-row> to character at <end-col>.
      • --show-error-end documentation explains the use-case:

        This flag will make mypy show not just that start position where an error was detected, but also the end position of the relevant expression. This way various tools can easily highlight the whole error span. The format is file:line:column:end_line:end_column. This option implies --show-column-numbers.

@karthiknadig
Copy link
Member

Please try this extension: https://marketplace.visualstudio.com/items?itemName=ms-python.mypy-type-checker It should handle --show-error-end automatically. That extension will be the eventual place for linting with mypy. It also used dmypy for performance.

@trinitronx
Copy link

trinitronx commented Aug 11, 2023

Suggested Solution

I'm not an expert at TypeScript, but from the looks of that code it seems feasible.

Also, based on the output of mypy I've observed so far... it looks like there may be some cases where both line == endLine and column == endColumn. Not sure if this is intended by mypy or a bug.

@trinitronx
Copy link

@karthiknadig Thanks! I just refreshed the page after typing up the above comment and saw the other extension suggested. I'll check it out to see if it works.

@trinitronx
Copy link

trinitronx commented Aug 11, 2023

@karthiknadig After testing out the new ms-python.mypy-type-checker extension, unfortunately it looks as if it did not work for me. There is an error in the MyPy Type Checker Output window logs:

2023-08-11 01:57:02.356 [info] /bin/python -m mypy.dmypy --status-file /tmp/.vscode.dmypy_status/status-0fff6c22-373a-40b3-a2b7-2e8f986ca857.json run -- --no-color-output --no-error-summary --show-absolute-path --show-column-numbers --show-error-code --no-pretty --follow-imports=silent --ignore-missing-imports --show-column-numbers --no-pretty --show-error-end /home/exampleuser/src/pub/testproject/src/testproject/config/config.py
2023-08-11 01:57:02.356 [info] [Trace - 1:57:02 AM] Received notification 'window/logMessage'.
2023-08-11 01:57:02.356 [info] CWD Server: /home/exampleuser/src/pub/testproject
2023-08-11 01:57:02.527 [info] [Trace - 1:57:02 AM] Received notification 'window/logMessage'.
2023-08-11 01:57:02.527 [info] dmypy: follow-imports=silent not supported

Manually running that python -m mpy.dmpy command without passing --follow-imports=silent seems to work ok. I can't get any output from VSCode's Problems window or otherwise.

EDIT: So, it looks like the old python.linting.mypyArgs were being picked up by the new plugin as this was found much earlier in the MyPy Type Checker Output logs:

Expand for MyPy Type CheckerOutput Window logs

2023-08-11 01:42:42.860 [info] Using legacy Mypy args from 'python.linting.mypyArgs': --follow-imports=silent --ignore-missing-imports --show-column-numbers --no-pretty.
2023-08-11 01:42:42.866 [info] Server run command: /bin/python /home/exampleuser/.vscode-oss/extensions/ms-python.mypy-type-checker-2023.2.0-universal/bundled/tool/lsp_server.py
2023-08-11 01:42:42.867 [info] Server: Start requested.
2023-08-11 01:42:43.298 [info] CWD Server: /home/exampleuser/src/pub/testproject
2023-08-11 01:42:43.299 [info] Settings used to run Server:
[
    {
        "cwd": "/home/exampleuser/src/pub/testproject",
        "workspace": "file:///home/exampleuser/src/pub/testproject",
        "args": [
            "--follow-imports=silent",
            "--ignore-missing-imports",
            "--show-column-numbers",
            "--no-pretty"
        ],
        "severity": {
            "error": "Error",
            "note": "Information"
        },
        "path": [],
        "interpreter": [
            "/bin/python"
        ],
        "importStrategy": "useBundled",
        "showNotifications": "off",
        "extraPaths": []
    }
]

It looks like this issue is python/mypy#9475.

I changed python.linting.mypyArgs to use --follow-imports=normal after testing that it was supported via: /bin/python -m mypy.dmypy run -- --follow-imports normal

At first, the plugin kept logging that it was using --follow-imports=silent. I had to force uninstall & re-install it again. Then it picked up the new setting and now appears to be working! 🎉

@trinitronx
Copy link

trinitronx commented Aug 11, 2023

... and now appears to be working! 🎉

It seems I may have spoken too soon. After some more testing, it appears that I'm running into a bug with similar behavior to: microsoft/vscode-mypy#88

After making no changes and re-saving the file, the new extension re-runs dmypy but all the Problem items disappear.

EDIT: I just tested following the suggestion to try setting mypy-type-checker.path to use mypy instead of dmypy. I chose the path of my system install of mypy: "mypy-type-checker.path": ["/usr/bin/mypy"]. Uninstall & reinstalled the extension again. Now it appears to work after saving.

@karthiknadig
Copy link
Member

@trinitronx I will be adding a setting to switch between daemon and regular mypy mode. That should make it easier to work with in that extension.

@karthiknadig
Copy link
Member

Closing this now as the mypy extension now has preferDaemon setting to switch between dmypy and mypy.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-linting bug Issue identified by VS Code Team member as probable bug
Projects
None yet
Development

No branches or pull requests

4 participants