Warnings disappear when opening files from the Error and Warnings quick box

[egamma]

I have a task defined that uses a problem matcher to create warnings.

Assume it creates 5 warnings for file A and 2 warnings for file B. The total warning count shown in the status bar is now 7.

Now follow these steps:

• Open View>Show Errors and Warnings
• Navigate to file A (do not fix any warnings)
• Open View>Show Errors and Warnings again
• Navigate to file B

At this point the warning count in the status bar drops to 2. This is confusing since without doing anything the 5 warnings have disappeared.

The reason is that when I open file A from Errors and Warnings it isn't put into the working files. Then when I open file B, File A is closed and its markers get cleared.

To avoid this confusion I suggest that opening a file from Errors and Warnings puts the file into the 'Working files' section, that is, the file is kept open and the warnings do not disappear. So the effect would be the same as if I double clicked the file from the explorer.

Assigning to Jo as the owner of diagnostics and the Errors and Warnings quick box. @dbaeumer fyi.

[jrieken]

interesting... maybe the task framework should even do it since that sort of owns the resources...

[joaomoreno]

I just hit this in the smoke test:

• Run the build task
• View the error list: some errors are there
• Ctrl click the file in which the errors occurred, in the output panel
• View the error list: errors are gone!

[jrieken]

@dbaeumer Is this maybe due to marker ownership conflicts between a task and a language worker?

[dbaeumer]

Not sure about @egamma case but @joaomoreno case is because of ownership. With Salsa we now validate the files with tsserver and no errors are produced. Since eslint-stylish uses the owner javascript Salsa clears all JS errors. May be for JS linters we should use a separate owner.

[egamma]

My example is using .ts files and tslint.

[stephenmartindale]

I can reproduce this problem in 0.10.14-insiders and with errors as well as warnings.

In my case, I have written a custom problem matcher. In my project folder, I have a host application and a web application and they both use TypeScript and have their own tsconfig.json and gulpfile.js. Errors are relative to whichever one I am building. For example, my problem matcher for the web sub-project looks like this:

{
                "owner": "gulp",
                "fileLocation": ["relative", "${workspaceRoot}/web"],
                "pattern": {
                    "regexp": "^(.*?\\.[dD]\\.[tT][sS]|.*?\\.[tT][sS])\\((\\d+)\\,(\\d+)\\)\\:\\s*(warning|error)\\s*(TS\\d+)\\:\\s*(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "message": 6
                }
            }

I experimented with various values for the owner property, including undefined, typescript and gulp (something I guessed wouldn't match any built in name) and, for all of them, some sort of weird behaviour can be observed. With gulp, errors are duplicated when I am actually on the file that has errors - presumably because the editor is raising its own - but, for all of them, navigating between files in the project eventually (not always after the first change of file) causes the errors to be lost.

[dbaeumer]

Moving to May. This is more complicated then I thought and requires some more investigation.

[stephenmartindale]

Colour me disappointed! This issue is causing me to waste hours scrolling up and down the output panel and manually eye-balling file names and line numbers - particularly when refactoring or renaming a variable or class member.

Perhaps you could implement a "band-aid" fix in the interim: simply shelve the concept of problem ownership clear all "problems" when a build starts and register them from the new build's output when it finishes. For intellisense problems, just bung them in as duplicates - naively append the intellisense problems and build problems.

[dbaeumer]

@stephenmartindale sorry about that. There are several possible interim fixes for your specific problem:

• if you only want to rely on the problems produce by the external gulp file keep your gulp owner in the problem matcher and add the following setting to your workspace settings

"typescript.validate.enable": false

This basically 'emulates' clearing all errors on build

• assuming that your gulp task is not a watching task you can enhance the problem matcher with the following property:

 "applyTo": "closedDocuments"

This will do the following: if a document is open in the editor errors are taken from the internal TS server and external errors are dropped. However in this setup you need to set the owner of the problem matcher to 'typescript' to make this work.

If this doesn't help, could you share your project. Then I have a quick look and see what I can do.

[dbaeumer]

I have written up a proposal for the new story here: #6973

[dbaeumer]

A couple of fixes went into the June build:

• linter problem matcher have now there own id. So a Salsa problem can't clear a eslint problem.
• the workbench doesn't auto remove errors anymore on close. It is up to the error producer to do so.
• the case described by @joaomoreno got addressed in VS Code's tasks.json by using the applyTo property.

I will close this issue. Any further discussion on how we proceed with project wide errors should be discussed here: #6973

[dbaeumer]

To verify with TS:

• open a TS file that has an error.
• close it and remove it from the list of working files

Ensure: the error is still presented in the list of errors

To verify with ESLint:

• install latest ESLint (0.10.18)
• open a JS file with an eslint error
• close that file. Ensure that the error disappears from the markers list.

[guidsdo]

Please, when is this going to be fixed?