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

[AntonVucinic]

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 (View→Output, 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: "" • 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

[karthiknadig]

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.

[AntonVucinic]

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

[trinitronx]

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:
  • 

• --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:
  • 

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]

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]

Suggested Solution

• Change the RegEx used to match mypy linter output to something like the following:

  (?<_filepath_prefix_here_ignore_this_group_>.?):(?\d+)(?::(?:::(?\d+))?)?: (?\w+): (?.)\r?(\n|$)

  • Feel free to tinker with this here
  • Note that:
  • In the code, each of the \ backslash characters is doubled up to escape them. This would need to be done to the above RegEx too.
  • The (?<_filepath_prefix_here_ignore_this_group_>.*?) part of the Regex is different in the code: ${escapeRegExp(filepath)}
  • The filepath gets passed in here to construct a dynamic RegEx, and I had no way of using dynamically generated RegEx on regex101.com link above
  • So, this was made a lazy .*? capture group to simply match everything before the part matching :line:column:end_line:end_column as our pattern of interest.
• Implement the optional capture groups endLine, endColumn in interface ILintMessage so they are handled by VSCode properly for MyPy linter.
  • Probably would need to override parseLine function from BaseLinter so endLine & endColumn are handled if found.
  • This could work similarly to how Pylint linter handles these, but note that Pylint uses IJsonMessage instead and translates this to an ILintMessage.

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]

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

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

[trinitronx]

... and now appears to be working! :tada:

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]

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

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