Fix #5137 async linting #6530

busykai · 2014-01-15T15:36:51Z

Implement support for asynchronous providers through scanFileAsync function. Each provider is limited by 500ms timeout now. Providers are executed in parallel (even though it only makes sense for the truly async ones). Providers are never rejected if actual provider rejects its promised, it is resolve with null results and does not appear in the problems panel.

Additionally some closure compiler notation issues in JSDoc have been fixed.

cc: @peterflynn, @ingorichter

Not working due to an issue in code inspection implementation (html template is displayed before it's rendered).

…nting Applied experimental version as the base for the development. Conflicts: src/language/CodeInspection.js

Use runPromise as the aggregation point instead of doing it in varios places.

busykai · 2014-01-15T15:38:20Z

Linking to discussion in #5137.

busykai · 2014-01-15T16:57:35Z

For the brave: checkout this async JSHint implementation if you want to test (checkout use-async-run branch, specifically). You need to place it somewhere where the extensions are loaded from, either in src/extensions/dev or in <AppSupportDirectory>/extensions/user.

ingorichter · 2014-01-15T23:02:05Z

@busykai I have a bunch of other stuff to do before we finish our sprint and I don't believe that I can pull this in, since we decided to focus on the new preferences system and the filesystem issues first. But I'm going to review this for Sprint 37.

busykai · 2014-01-15T23:05:43Z

@ingorichter that's fine, this was pointing at Sprint 37. I understand the timing. Unit tests are missing too, like you rightfully mentioned. :)

busykai · 2014-02-26T12:46:20Z

@ingorichter, would you have a chance to look at it anytime soon?

njx · 2014-02-26T21:25:01Z

Looks like @peterflynn is currently assigned to this.

…nting Conflicts: src/language/CodeInspection.js

ingorichter · 2014-03-05T17:57:09Z

@busykai Sorry that it took so long for us to get to this PR. I'll look at it today.

busykai · 2014-03-06T02:10:33Z

@ingorichter, great! thank you!

ingorichter · 2014-03-07T17:56:06Z

I'm currently testing some edge cases. I hope to be finished by today.

fdecampredon · 2014-03-08T19:42:34Z

Like I said to Peter Flynn on IRC, I develop my extension (TypeScript language support) using the code of this PR . My linter runs in a Web Worker and everything works fine except that when I open brackets with a TypeScript files open I got the 2 following errors in the chrome console :

Recursive tests with the same name are not supported. Timer name: CodeInspection:   
/Users/kapit/Documents/workspaces/typescript/brackets-typescript/src/commons/completion.ts PerfUtils.js:116
Recursive tests with the same name are not supported. Timer name: CodeInspection 'TypeScript':  
/Users/kapit/Documents/workspaces/typescript/brackets-typescript/src/commons/completion.ts PerfUtils.js:116

I guess that at start times if the linter takes a little times to answer (that is the case here since the typescript compiler takes a little time to load and parse all the files of the current project) 2 inspection are launch in parallel resulting in these errors.

ingorichter · 2014-03-14T21:01:30Z

test/spec/CodeInspection-test.js

+            };
+            spyOn(provider, "scanFileAsync").andCallThrough();
+
+            if (syncImpl === true) {


little nit: if (syncImpl) { should be sufficient here.

…nting

peterflynn · 2014-03-31T07:44:21Z

@busykai Ah, I think I see what's going on: there's existing code in run() that bails if the current file has changed since the linting was kicked off. But there's nothing more generalized to ensure we ignore all stale promises, so the other race conditions I listed above could still happen. I can post some failing testcases if it'd be helpful.

Here's one idea for a fix: have a module-global variable that holds the "current" pending promise. Overwrite it whenever a new run() is initiated (overwrite with null if !_enabled). In the then() handler, check if the promise is still the current one and if not, bail. That could replace the current-document check code since it's essentially a superset of it.

Keep track of the last promise which inspectFile returns to prevent any stale promises from updating the UI.

busykai · 2014-03-31T23:43:54Z

@peterflynn, changed the check as per your suggestion.

@ingorichter, this is ready for another round of review.

peterflynn · 2014-04-02T22:03:52Z

src/language/CodeInspection.js

+                                type: Type.ERROR
+                            };
+                            runPromise.resolve({errors: [errTimeout]});
+                        }, prefs.get(PREF_ASYNC_TIMEOUT));


I still think we should remove this timeout -- it breaks use cases like retrieving linting results from a web service, and it's something we don't do in any of our other async provider-based APIs. And I don't see a clear reason why we need it (especially with the race condition guard that makes us ignore stale promises, even if they dangle forever).

If we must keep it, we should make the default timeout significantly longer and use Async.withTimeout() to simplify the code here.

In the current model, any hanging request actually delays the entire rendering. I agree with you and Ingo that this is a fragile with regards to the linters which may take long, but it could be addressed incrementally (e.g. make results rendering incremental without re-running all the linters). It should not be holding up this PR. This is already way better than nothing. Existing linters can take advantage of this. This is all started just because I wanted to support recursive configuration file look up in JSHint which can be done right now. I don't see this is piece of code as a step in an opposite direction.

I understand those are your needs, but there are multiple other people who've requested this specifically in order to get web services or node-side services into the picture. I don't think we can call #5137 fixed if we're timing out after just 1 sec. How about we just raise it to 5 or 10 sec for now?

It also seems weird that this is a single global pref rather than an option linters can specify when registering, or a per-linter pref. I think we'll need to revisit that if there are complaints about the default timeout, but for now it seems ok (as long as we bump up the default here).

In my case like I explained on IRC, my initial lint can take few seconds on large projects (while the subsequent will be faster). So if you go with the timeout a bigger one would make me happy.

OK. Let's make it 10 secs for now. I guess my PoV was limited to the uses cases I was exposed to. I filed #7397 which is the right way to deal with this entire timeout issue.

peterflynn · 2014-04-02T22:28:19Z

src/language/CodeInspection.js

+                results.sort(function (a, b) {
+                    // actual provider list may have changed in the process, but we don't care
+                    return _.indexOf(providerList, a.provider) - _.indexOf(providerList, b.provider);
+                });


Any reason to not do this in inspectFile() instead, so all clients get consistently sorted results like they have been getting previous sprints?

Also, I'm a little confused about the "provider list may have changed in the process" - you mean during the async delay, new providers may have been registered?

Also, I think a simple providerList.indexOf() would work fine here

@peterflynn, I guess my line of thinking was not to sort it before there's a chance it can be discarded. will change to use Array's indexOf.

Oh, you mean if the promise is stale? I think the perf hit of sorting discarded linting results is pretty negligible -- on balance, it seems better to have the API do the right thing for all clients instead of making everyone rewrite this piece of code.

peterflynn · 2014-04-02T23:05:24Z

@busykai Done with re-review. Just a bunch of small things at this point I think.

- Sort the results immediately in inspectFile. - Refactor the tests. Set timeout low for the tests to run faster. - Increase timeout to 10 seconds.

busykai · 2014-04-04T21:57:24Z

@peterflynn done with addressing comments. please take a look.

…nting Conflicts: src/nls/root/strings.js

peterflynn · 2014-04-08T04:59:39Z

@busykai This looks great! -- nothing left that should really hold up merging. I'm just going to do a little hand-testing tonight before pushing the button...

peterflynn · 2014-04-08T19:08:03Z

Merging now. Thanks for all your work on this @busykai!

Support linting providers that return results asynchronously

busykai · 2014-04-09T12:32:18Z

Yay! Great! Now to improve it! :)

- Fix bug: if one linter returns errors and another returns errors:[], the no-errors linter is shown in the panel as an empty heading. (Bug doesn't happen if it returned null instead; but both are valid ways of indicating zero errors). - Improve docs on register() - more concise, more detail on how to indicate zero errors - Add unit tests for the bug fixed above plus several more async linting cases that were fixed late in PR #6530 - Fix mislabeled existing unit test for reject()ing async linters - Fix stray whitespace that snuck into merge c3411bb

busykai added 6 commits January 3, 2014 17:10

Bare async provider implementation.

835b3af

Not working due to an issue in code inspection implementation (html template is displayed before it's rendered).

Merge remote-tracking branch 'origin/fix-5137' into fix-5137-async-li…

db33c0f

…nting Applied experimental version as the base for the development. Conflicts: src/language/CodeInspection.js

Fix @param specification error.

e730595

Change documentation and JSDoc.

d9deaa1

Put timeout on provider execution.

b91ec3f

Use runPromise as the aggregation point instead of doing it in varios places.

Change to record notation (understood by CC).

08e0392

Fix typo in the docs.

03c9ed3

ghost assigned peterflynn Jan 15, 2014

busykai added 2 commits January 16, 2014 20:50

Resolve with null on timeout. Lint.

5ec5534

Add unit tests.

9fc0425

This was referenced Jan 21, 2014

Changed CodeInspector.inspectFile to accept provider.scanFile functions that return the result via a promise #6606

Closed

Look for JSHint config info in jshintConfing property of package.json. cfjedimaster/brackets-jshint#26

Open

Merge remote-tracking branch 'upstream/master' into fix-5137-async-li…

62933ce

…nting Conflicts: src/language/CodeInspection.js

This was referenced Mar 4, 2014

Problem with Project.getAllFiles #7073

Closed

Code completion not working fdecampredon/brackets-typescript#18

Closed

ingorichter reviewed Mar 14, 2014
View reviewed changes

busykai added 2 commits March 17, 2014 10:25

Merge remote-tracking branch 'upstream/master' into fix-5137-async-li…

d684e93

…nting

Address code review comments.

0c091df

Check for current promise instead of document.

c786e69

Keep track of the last promise which inspectFile returns to prevent any stale promises from updating the UI.

peterflynn reviewed Apr 2, 2014
View reviewed changes

Remove left-over documentation sentence.

a075ab4

peterflynn reviewed Apr 2, 2014
View reviewed changes

busykai mentioned this pull request Apr 3, 2014

Code inspection should render providers' results independently one from another #7397

Open

fdecampredon mentioned this pull request Apr 4, 2014

Quick Find Definition not working fdecampredon/brackets-typescript#17

Closed

Address review comments.

a46b9df

- Sort the results immediately in inspectFile. - Refactor the tests. Set timeout low for the tests to run faster. - Increase timeout to 10 seconds.

Merge remote-tracking branch 'upstream/master' into fix-5137-async-li…

c3411bb

…nting Conflicts: src/nls/root/strings.js

peterflynn added a commit that referenced this pull request Apr 8, 2014

Merge pull request #6530 from busykai/fix-5137-async-linting

9111c08

Support linting providers that return results asynchronously

peterflynn merged commit 9111c08 into adobe:master Apr 8, 2014

busykai deleted the fix-5137-async-linting branch April 9, 2014 12:32

EvHaus mentioned this pull request Apr 17, 2014

Investigate support for async linting in Brackets EvHaus/brackets-jscs#7

Closed

peterflynn mentioned this pull request Apr 25, 2014

Code Inspection: minor fixes & more unit tests #7650

Merged

core-ai-bot mentioned this pull request Aug 30, 2021

[CLOSED] Fix #5137 async linting brackets-archive/bracketsIssues#5935

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix #5137 async linting #6530

Fix #5137 async linting #6530

busykai commented Jan 15, 2014

busykai commented Jan 15, 2014

busykai commented Jan 15, 2014

ingorichter commented Jan 15, 2014

busykai commented Jan 15, 2014

busykai commented Feb 26, 2014

njx commented Feb 26, 2014

ingorichter commented Mar 5, 2014

busykai commented Mar 6, 2014

ingorichter commented Mar 7, 2014

fdecampredon commented Mar 8, 2014

ingorichter Mar 14, 2014

peterflynn commented Mar 31, 2014

busykai commented Mar 31, 2014

peterflynn Apr 2, 2014

busykai Apr 2, 2014

peterflynn Apr 2, 2014

fdecampredon Apr 3, 2014

busykai Apr 3, 2014

peterflynn Apr 2, 2014

peterflynn Apr 2, 2014

busykai Apr 3, 2014

peterflynn Apr 3, 2014

peterflynn commented Apr 2, 2014

busykai commented Apr 4, 2014

peterflynn commented Apr 8, 2014

peterflynn commented Apr 8, 2014

busykai commented Apr 9, 2014

Fix #5137 async linting #6530

Fix #5137 async linting #6530

Conversation

busykai commented Jan 15, 2014

busykai commented Jan 15, 2014

busykai commented Jan 15, 2014

ingorichter commented Jan 15, 2014

busykai commented Jan 15, 2014

busykai commented Feb 26, 2014

njx commented Feb 26, 2014

ingorichter commented Mar 5, 2014

busykai commented Mar 6, 2014

ingorichter commented Mar 7, 2014

fdecampredon commented Mar 8, 2014

Choose a reason for hiding this comment

peterflynn commented Mar 31, 2014

busykai commented Mar 31, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peterflynn commented Apr 2, 2014

busykai commented Apr 4, 2014

peterflynn commented Apr 8, 2014

peterflynn commented Apr 8, 2014

busykai commented Apr 9, 2014