limit number of analyzer errors produced

[danrubel]

Too many errors causes user scroll blindness and overwhelms a machine's capacity to display them. I recommend we limit the number of errors produced per file, per context, and per module root. In IDEs such as IntelliJ, users can filter errors to just those for files in a given module root or directory, so I would not want a cap on the overall number of errors produced.

[bwilkerson]

I would prefer to see the limits imposed on the client side for a couple of reasons. First, I don't want to make it impossible for clients to provide alternate access to those errors. Second, while server could limit the number of errors reported for a given file, it would be required to compute all errors before returning any if it were responsible for limiting at larger levels of granularity.

@devoncarew @jwren

[devoncarew]

I have put limits in some tools in the past. For Atom, displaying too many issues would slow the tool down - the errors view was not visualized so all the errors were real nodes in the DOM. I think I used something like a cap of 200 errors per file and 500 per project. When capping, I'd then create a new final issue to say that not all errors were reported.

It does (and did) have issues where the cap was too low for some projects, and people would miss problems we weren't reporting. Definitely a tricky area.

Perhaps if there's some fundamental issue with the project, we should report that? Brian did some work around showing errors for generated code; if there was a missing import, and we could tell that the import was of a generated file, we just show the error for that import and not for all the follow on errors about missing symbols from that particular import.

[danrubel]

All these are valid points. The issue in question happened in IntelliJ where it was trying to display 500,000 errors and needless to say the machine was not happy.

[devoncarew]

That's a lot of errors! At some point it does make sense to cut bait.

/cc @alexander-doroshko

[danrubel]

Should we provide the capability for clients to specify per file and per project limits for analysis server? Better for analysis server to stop producing them rather than shipping them over the wire just so that the client can drop them on the floor.

[jwren]

When the Dart Analysis view was initially implemented @alexander-doroshko stress tested it with large numbers of errors and warnings, I don't know if he tested it up to this many.

If not all errors are shown in the Analysis view, we should indicate it in the UI.

[alexander-doroshko]

I tested with 100,000 and Dart Analysis view worked absolutely smoothly on my machine.
I agree that it is up to client whether to limit it or not. I see no reasons to implement it at server side.