Problems view: Sort by message

[elenadimitrova]

Working with the problems tab in the panel, issues are grouped by file. Although this is useful, certain dev workflows require dealing with one problem type (EDIT: by problem type here we mean the problem message) at a time and therefore grouping problems by type would be useful. Current view for comparison

Note that this feature had been requested before #41114 and while the moderator has closed it with the argument that filtering functionality can meet this requirement, I am reopening the discussion here, more than 2 years down the line, for reconsideration. Where filtering alone fails is allowing for wider analysis of the number of occurrences of different problems across the solution i.e. is it a widespread problem with say 10-20 occurrences or is it just a single instance. This is essential when performing large refactoring or code upgrades where we have to deal with tens or even hundreds of problems at a time.

Additionally in support of this I am attaching a screenshot of how Visual Studio problems panel displays which many of us coming from the Enterprise are used to with writing C#. Currently all those capabilities are present in VS Code except for the default grouping of problems we get.

[sandy081]

Where filtering alone fails is allowing for wider analysis of the number of occurrences of different problems across the solution i.e. is it a widespread problem with say 10-20 occurrences or is it just a single instance. This is essential when performing large refactoring or code upgrades where we have to deal with tens or even hundreds of problems at a time.

We provide above filters and can you please explain how above filters is not helping your requirement and how grouping is helpful.

[elenadimitrova]

I was talking about code changes where there are potentially tens of problems reported across many files. Sorting by error type allows us to understand how widespread each compile error is and prioritise those in order of number of occurrences for example. The filtering only allows us to get that information one error type at a time which is only useful when you know what you want to fix next.

[sandy081]

Sorting by error type allows us to understand how widespread each compile error is and prioritise those in order of number of occurrences for example.

I am not saying that this is the right way but I think you can also get this information by toggling the filters and get the numbers and prirotize what type to fix ?

I am actually looking for a strong use case to get this feature.

[elenadimitrova]

This means searching for each error type one by one, analyse occurrences of each then summing it all up to decide where to start from. The effort grows exponentially with number and variety of problems reported. When #13953 is implemented, I feel it will be even more of a problem as we'll have to be filtering through much larger problems output by default.

[sandy081]

There are only 4 types and Problems view shows only 3 types. Mostly 2 types are more prominent (errors and warnings).

analyse occurrences of each then summing it all up to decide where to start from.

Not able to figure out the issue here to decide where to start among 2 types (max 3) ?

[elenadimitrova]

Yes I see where the confusion is. Let me use an example from the actual problems list output here (Solidity compilation result for Ethereum):

{
	"resource": "/contracts/legacy/TokenPriceProvider.sol",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "Source file requires different compiler version (current compiler is 0.6.8+commit.0bbfe453.Emscripten.clang) - note that nightly builds are considered to be strictly less than the released version",
	"startLineNumber": 17,
	"startColumn": 1,
	"endLineNumber": 17,
	"endColumn": 24
}
{
	"resource": "/contracts/modules/storage/GuardianStorage.sol",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 4,
	"message": "security/no-block-members: Avoid using 'now' (alias to 'block.timestamp').",
	"startLineNumber": 134,
	"startColumn": 49,
	"endLineNumber": 134,
	"endColumn": 5146
}
{
	"resource": "/lib/maker/jug.sol",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "Source file requires different compiler version (current compiler is 0.6.8+commit.0bbfe453.Emscripten.clang) - note that nightly builds are considered to be strictly less than the released version",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 1,
	"endColumn": 24
}

In this abbreviated case, I would like to be able to sort by the message string so the first and third errors are grouped together and I can fix at once.

[sandy081]

I see you want to see problems sorted by message and you can go through them. But why do you need grouping by type?

[elenadimitrova]

Define "type" here pls as we're probably talking about different things.

[sandy081]

By type I mean severity. Sorry for not being clear.

[elenadimitrova]

Thanks for clarifying, then I wasn't talking about the severity at all here. I was referring to grouping by the problem message as given in the example above.

[sandy081]

I assume by grouping you mean sorting by message?

[elenadimitrova]

Yes

[Arthurm1]

I agree with the Visual Studio example given above by @elenadimitrova. A table (with filedir, filename, severity, message) sortable by any number of columns, would be a great help. Especially if each column was individually filterable by regex. More info like error position could be added but I don't see that as useful when looking at a list of problems.

Initially I thought being able to toggle between the current Problems tree-view (file node + message leaf) and a table would be perfect but I'm struggling to understand what the advantage is of having a tree-view (or the ability to collapse it) at all compared to having a table. Is there any workflow where the tree-view is better? It takes up an additional line on the screen for every file which having a table wouldn't need and, when collapsed, any knowledge of what the problems are is lost, except for the file and number per file which I don't see as very useful without the message. It's not sortable by field (i.e. severity, message, filename). So I'd propose ditching the treeview completely for a table.

The times where I run into this issue is in cases of large refactorings where some changes (e.g. an upgrade of a major library version) can cause thousands of messages and being able to sort them and scroll down through the different messages can give a good overview of the ramifications i.e. whether there are any show-stoppers that might result in having to rollback, roughly how much time fixing those issues might take, whether other coders need to be involved etc.

[bbalp]

@sandy081 As far as I understand it, solving this issue would let the user have a Problems pane flat, with no grouping of any sort. By default, can we have this flat list of problems, be sorted in the order the task output generated it? This is a huge necessity in C++!

Multiple issues already have been posted here about that problem. The one that could have saved C++ devs from this nightmare of finding the first error in task output was #18685. Never made it because never got enough support and was automatically closed. I am thinking about recreating an issue, but found this one here, thought I would ask before doing anything.

[sandy081]

be sorted in the order the task output generated it?

If we support sorting, then the default would be to show in the order how extensions/tasks have contributed it.

[bbalp]

As I can see this feature is being worked on, I would like to share a thought.

When there is no sorting column defined by the user, because I got confirmation that the order will be the one the different extensions and tasks have contributed to it, the following situation came to my mind.

When I run my C++ build, I get my problems in a very specific order from my task. I want (need) to keep it like that. But, there is also the Intellisense that contributes to the list of problems dynamically. Like for example, when I am opening a file, reading it. Then, a list of problems can pop up in my Problems pane. When I close the file, the problems disappear. There are two things here.

1. As this is inherently dynamic, and supposed to be useful, they shouldn't be added at the end of the problem list. Because they came up after I ran a task for example. In the C++ case, it's very easy to have thousands of problems when building a very basic piece of code, it is a very common situation. So adding the Intellisense problems would automatically mean, we never gonna see them sometimes. Because in C++ we are always interested in the top of the list of problems from our build task.
2. The list of problems generated by Intellisense can be different from the one the build task has generated for the same file. It won't make sense to merge them all blindly. As an example, in C++ only the build problems are guaranteed to be interesting to fix my compilation, the Intellisense is very useful to give me hints on very probable problems on the other hand. (Having both matching exactly is not easy.)

Where then? where to add these dynamic problems?

• Probably in a separate group of problems (grouping by source?)
• Or maybe having a column to push in front of (or at the end of) the list the problems we are interested in (or not) while still keeping the order of the problems for the same source the same as they have been pushed by it
• Something else?

So, to sum it up. I am very excited to see that, soon, I gonna have my list of problems sorted the way they have been pushed by my task!! But, probably don't merge problems from different sources without letting the user know and choose what to display.

[gayanper]

Today when problems view shows all problems from different sources. For example you could see lot of problems in a java workspace. Problems from java LS, Sonar LS and Maven LS (redhat xml) all will be shown in the list. It would be nice if the problems can be grouped so it will be easy to focus on each problem type. Another alternative for grouping is add the same support into filtering which will also solve the above use-case.

[lszomoru]

The latest Insiders release have a new action in the toolbar of the "Problems View" that allows users to toggle between seeing the problems in a tree view or a table. The table has a dedicated column for the source of the problem, so after switching to the table view, you can use the existing filter capabilities to filter the problems by source.

[bbalp]

Thank you very much for you work @lszomoru. I just tried your work on the insiders branch. I like the direction it is taking. It is a great improvement to know from which source a problem comes from. But on a C++ point of view, it remains unusable as long as the problems are not displayed in the same order they have been found in task / extension output. I guess this is something that could come soon, but the nice things always take time.

[lszomoru]

@bbalp, thanks for trying out the new visualization and thanks for your feedback. I will review your feedback so that I get more context on your comment: "But on a C++ point of view, it remains unusable as long as the problems are not displayed in the same order they have been found in task / extension output.". I am planning on adding more sorting options probably next milestone.

[bbalp]

@lszomoru Great! To give you more context, here is the situation.

In C++ there are situations where you get "cascading errors". Particularly when you are using templates. Meaning you missed something, and the compilers continue to try to do its job with the rest of the code, but when errors are the consequence of the first error, you may get a lot of false positives ... like a LOT. Even with the easiest and simplest program, using templates from the standard library itself, forgetting a semi-colon ; in you program could cause like 700 errors ... but only the first one is relevant.

In this case it's pretty easy to just ignore those false-positives coming from files you don't own (standard library headers), but in a complex project you easily get many false-positives from your own code. And it's not always obvious there are false-positives ... So you are doomed to solve the errors in the order the compiler output them. Because the first error, is the only one guaranteed to not be the consequence of another one ...

That's why grouping the problems by files like does the tree-view is absolutely unuseful in this context. And if we get a table-view that doesn't keep the order the errors are discovered from the build task output ... it is not useful either.

So what is needed to fulfil the requirements regarding C++ use cases? Keeping the order of problems (errors, warnings, etc.) found in the build task.

What about sorting? (table-view)

• Yes, it is useful to sort the table-view clicking on column headers. It can be useful to sort by source in particular. Even though filtering would fulfil the same goal in this situation.
• It would be absolutely fantastic to keep the order within a group ... like if I sort by source 700 problems and there are only 2 sources, keeping the order within the same source.
• It is absolutely necessary that we can "remove" any sorting settings to get back to the original order of problems.
• If we get dynamic entries ... from the Intellisense for example when clicking on files to view them. Without any sorting set by the user, it is probably expected to get the problems appear first in the list, not after the 700 errors from the previous build task. The user could sort/filter the column by source I guess to get what matters. But it raises the question of which criteria can be used to define an ideal ordering of the problems by default, without any sorting set by the user, when mixing tasks problems and Intellisense problems! And I don't know if currently the problems are added one by one, or in batch, and if it may play a role in the situation ... But the case I have in mind is, running a build task, having 700 errors sorted correctly, so the oldest to the newest, but then getting Intellisense errors, so there are newer, but not at the end of the list ... Maybe adding an error from a source, bring back on top all the problems from this same source? Useful in C++, very specific, maybe not that useful in other languages, or even disturbing to have by default? I don't have a perfect solution.

What about grouping? (tree-view)

• Only one situation where it is useful in C++, contextual information about the error can be nested into the error node itself. It seems the CMake extension currently does that with the tree-view, errors are still grouped by file, but also some errors are grouping their own contextual info. Grouping by file is still not useful, but grouping any contextual info is nice. But if we just list the contextual info like any problem in table-view and keep the order, it's fine! Because they appear just after the error they are related to. So grouping is nice, but it's not a requirement in any way.

To sum up, there is only one priority regarding the C++ use case, somehow being able to keep the original ordering of problems from the build task ... and it implies we have a way to know the source, but this part is already done! :) Everything else is an extra.

[darsor]

Clicking on table headers to sort problems would absolutely be useful in my workflow. Pretty much every HDL tool generates hundreds if not thousands of warnings, most of which are useless, but some of which are critical. Each warning has a code associated with it that a problem matcher can extract.

It would be very useful to sort these problems by their error/warning code in order to pick out the relevant bits. The alternative would be to incrementally hide useless error codes, but the problem filter doesn't currently support multiple negative expressions.

As an aside, the "code" column of the table shows "-" for everything, even though copying the JSON from the table shows the code field as defined. Maybe it's expecting a purely numeric value?

[lszomoru]

As an aside, the "code" column of the table shows "-" for everything, even though copying the JSON from the table shows the code field as defined. Maybe it's expecting a purely numeric value?

@darsor, this seems like a bug. Are you able to reproduce this issue in the latest Insiders release? If so, could you please provide me with the sample project and repro steps so that I can reproduce and investigate the issue. Thank you!

[matefriedl]

hi @lszomoru, I have ran into the problem described by @darsor recently and made a simple repro: https://github.com/matefriedl/vscode-problem-code-repro