[CLOSED] Fix #5137 async linting

[core-ai-bot]

Issue by busykai
Wednesday Jan 15, 2014 at 15:36 GMT
Originally opened as adobe/brackets#6530

---

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

---

busykai included the following code: https://github.com/adobe/brackets/pull/6530/commits

[core-ai-bot]

Comment by busykai
Wednesday Jan 15, 2014 at 15:38 GMT

---

Linking to discussion in #5137.

[core-ai-bot]

Comment by busykai
Wednesday Jan 15, 2014 at 16:57 GMT

---

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.

[core-ai-bot]

Comment by ingorichter
Wednesday Jan 15, 2014 at 23:02 GMT

---

@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.

[core-ai-bot]

Comment by busykai
Wednesday Jan 15, 2014 at 23:05 GMT

---

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

[core-ai-bot]

Comment by busykai
Wednesday Feb 26, 2014 at 12:46 GMT

---

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

[core-ai-bot]

Comment by njx
Wednesday Feb 26, 2014 at 21:25 GMT

---

Looks like@peterflynn is currently assigned to this.

[core-ai-bot]

Comment by ingorichter
Wednesday Mar 05, 2014 at 17:57 GMT

---

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

[core-ai-bot]

Comment by busykai
Thursday Mar 06, 2014 at 02:10 GMT

---

@ingorichter, great! thank you!

[core-ai-bot]

Comment by ingorichter
Friday Mar 07, 2014 at 17:56 GMT

---

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

[core-ai-bot]

Comment by fdecampredon
Saturday Mar 08, 2014 at 19:42 GMT

---

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.

[core-ai-bot]

Comment by busykai
Monday Mar 17, 2014 at 14:50 GMT

---

@ingorichter made the changes as per review.

[core-ai-bot]

Comment by busykai
Monday Mar 17, 2014 at 14:59 GMT

---

@fdecampredon, what about an interface which would allow you to enable/disable your provider? i was trying to think of a generic API to support provider lifecycle like yours, but then it gets too complicated when trying to embrace all possible conditions when a provider may want to go offline for a while. instead, a much simple approach is to give the provider a way to indicate when it's ready and when it's not.

[core-ai-bot]

Comment by ingorichter
Monday Mar 17, 2014 at 15:44 GMT

---

I wrote a unit test for the race condition and we need to check, if the document is still the same when the inspection/linting results will be displayed. My case was to open a document, start inspection, close document and the results for the previous document will show up in the bottom panel. This shouldn't be too difficult to avoid for us.

[core-ai-bot]

Comment by busykai
Monday Mar 17, 2014 at 16:09 GMT

---

@ingorichter, that's weird. i had this case in mind. isn't it what line 312 does already? it's done when Async.doInParallel is settled. could you push your testcase here so i can work on it? scratch that last one, it's actually a PR from my previous life.

[core-ai-bot]

Comment by fdecampredon
Tuesday Mar 18, 2014 at 00:41 GMT

---

@busykai yep enabling/disabling could be a cool way of handling inspector like mine, especially if a lint session is started when a linter get enabled.