add registered ProblemMatchers to tasks schema

[elaihau]

• With this pull request, task schemas are updated on problem matchers
  being added / disposed, and users are benefited from having content assist while specifying the name(s) of problem matcher(s) in tasks.json.
• resolves [tasks] add registered 'ProblemMatchers' to the 'tasks.json' schema #6134

Signed-off-by: Liang Huang liang.huang@ericsson.com

How to test

• Open tasks.json and define a task.
• Add "problemMatcher" to the defined task, and check if we are able to see the names of registered problem matchers.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

[elaihau]

@akosyakov this is the part i am not sure about.
could you please give me more information on what /* mark as not disposed */ means here? Thank you !

[akosyakov]

isDisposed returns true if a collection is empty. If we don't add anything on the initialization when checking it returns false, so we push an empty disposable object to indicate that it was not disposed yet.

[vince-fugnitto]

I verified if we now get content assistance when editing the tasks.json manually and it works correctly 👍
I also correctly get warned when attempting to provide unknown problem matchers.

[vince-fugnitto]

@elaihau do you mind documenting this method?
I see that we getAll named problem matchers, reset the current list, and finally push the new list.
I just wanted to understand why it's required and in what scenario.

[elaihau]

Yep i will document this function.

This function is called in the callback of this.problemMatcherRegistry.onDidChangeProblemMatcher( ). In other words, every time a problem matcher is registered or disposed, we want to update the task schema to ensure the users get the most up-to-date when they are manually entering the problem matcher(s).

I cannot simply do problemMatcherNames = matcherNames; instead of resetting the length of array, as the reference of problemMatcherNames is assigned to the task schema when theia starts.

[RomanNikitenko]

Tested the changes:

• the names of registered problem matchers are displayed when I edit tasks.json file manually
• warning is displayed when I try to use unregistered problem matcher for a configuration

[vince-fugnitto]

@elaihau I noticed something, when executing a task (ex: test task under tasks/test-resources), I selected the builtin problem matcher eslint-stylish. When looking at the 'tasks.json', the editor complains that the problem matcher does not exist, likely due to the **$**.

[elaihau]

@elaihau I noticed something, when executing a task (ex: test task under tasks/test-resources), I selected the builtin problem matcher eslint-stylish. When looking at the 'tasks.json', the editor complains that the problem matcher does not exist, likely due to the **$**.

wow nice catch !
should we put both $eslint-stylish and eslint-stylish in the list? it is a dilemma ... as looks a little redundent.
Maybe ... instead we could do something to make sure the problem matcher auto-added by theia always starts with "$"? what do you think? Thanks!
@vince-fugnitto

[vince-fugnitto]

wow nice catch !
should we put both $eslint-stylish and eslint-stylish in the list? it is a dilemma ... as looks a little redundent.
Maybe ... instead we could do something to make sure the problem matcher auto-added by theia always starts with "$"? what do you think? Thanks!
@vince-fugnitto

From looking at VS Code, it looks like they register the builtin problem matchers with the $ included.
Perhaps, we should add to the schema only one instance for each with the $ included as well.

[elaihau]

From looking at VS Code, it looks like they register the builtin problem matchers with the $ included.
Perhaps, we should add to the schema only one instance for each with the $ included as well.

Yes you are right. I updated the code to match the vs code behavior. Thank you !

[vince-fugnitto]

It works much better now thank you! 👍