mypy output not correctly parsed with `--show-column-numbers`

Environment data

• VS Code version: 1.24.1
• Extension version (available under the Extensions sidebar): 2018.6.0
• OS and version: 10.13.5
• Python version (& distribution if applicable, e.g. Anaconda): 3.6.4 (homebrew)
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): N/A
• Relevant/affected Python packages and their versions: mypy 0.610

Actual behavior

When the --show-column-numbers flag is used with python.linting.mypyArgs, the output is no longer parsed correctly. No Problems appear and no editor underlining occurs.

mypy output is still output to the Output tab.

Expected behavior

Mypy lint output parser should be agnostic to the --show-column-numbers flag.

Steps to reproduce:

1. Have mypy installed and in $PATH

2. Create a file with an incorrect types:

   # foo.py
   def foo(bar: int):
       pass
   
   
   foo("bar")
   

3. Save and notice that mypy output correctly shows Problem and editor error indicator.

4. Update python.linting.mypyArgs to (i.e. add --show-column-numbers flag):

     "python.linting.mypyArgs": [
       "--ignore-missing-imports",
       "--follow-imports=silent",
       "--show-column-numbers"
     ],
   

5. Notice that Problem and error indicator no longer appear, but output is still run but now contains column number.

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

##########Linting Output - flake8##########
##########Linting Output - mypy##########
test.py:5:1: error: Argument 1 to "foo" has incompatible type "str"; expected "int"

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help)

N/A

[brettcannon]

@sudowork OK, then I’m going to leave this open as an enhancement that we would happily take a contribution for but that we aren’t going to prioritize right now.

[brettcannon]

To help manage our issues and to better communicate what the team plans to work on we are closing issues that we don’t plan to work on but would accept a pull request from a volunteer for. To be clear, closing this issue does not mean we won’t consider a pull request for this enhancement as outlined in our contributing guide, just that the development team has no plans to work on it themselves.