Freeze with problems panel with quick fixes

[mjbvz]

Repo

1. With the tslint plugin extension installed
2. Run tslint --init in an empty folder
3. Now create a TS file:

const foo = 123;

food
food
food
// repeated about 200 times
food

1. Open problems panel

Bug
Entire app freezes

[mjbvz]

The freeze is in mainThreadHeapService inside _doTrackRecursive.

The size of the stack array becomes insanely large here. Possibly a circular reference?

[mjbvz]

Here's what I think is happening:

1. problems panel requests code actions for entire document range.
2. Because tslint is installed, we include a fix-all quick fix with each diagnostic in the file
3. Each of these fix-all actions includes 200+ edits to the file.
4. This means that the resulting object we pass to the heap service includes something like 200 edits for each of the 200+ errors, i.e. it is really big

I don't think the markers panel should requests quick fixes for the entire document. Can we make this lazy instead, like how we request errors while moving the cursor through a file?

As a workaround for now, we could also cap the number of code actions that getCodeActions returns. You can hit the same problem if you select the entire file

[mjbvz]

@jrieken Do we need to call trackRecursive on code actions in mainThreadLanguageFeatures? Code actions don't have a separate resolve step so I'm not sure if calling trackRecursive is required

[jrieken]

@jrieken Do we need to call trackRecursive on code actions in mainThreadLanguageFeatures?

We need it for command arguments. When an "old" code action aka command comes it we track that because the arguments for that command aren't send to the main but stored on the ext-host side. Once the code action gets GC'ed (on the main side) we let go off the arguments.

One trick would be to know if we have to do that, e.g a "modern" code action using text edits doesn't need this at all. But that only fixes half the problem, e.g old code actions still exist. A real fix would be the introduction of a proper lifecycle - we have done that with completions.

[sandy081]

To show light bulbs, problems panel is making single request per visible file to get code actions for complete file and compute it for each entry with the received data instead of asking code actions for each problem entry.

@mjbvz I used the same example as yours with 250 problems and I do not see any freeze.

Is there a different example to try out?

[mjbvz]

Make sure you have the tslint plugin installed and have a recommended tslint config (tslint —init)

I don’t think we should be making these requests eagerly. Even without this bug, that’s a lot of extra communication and cycles for information we almost always discard. My proposal is to request the code actions for a single problem when you hover or focus the problem itself.

[sandy081]

Changed the strategy to fetch code actions when

• Selected
• Focused
• Hover for 300ms
• Context Menu
• Triggered from Keyboard

code actions are fetched only once per marker irrespective of all above events.

[jrieken]

I have also pushed a change that gets rid of trackRecursive making it explicit (trackObject). This ensures we only track objects of interest and stop traversing arbitrary object trees