Bugzilla – Full Text Bug Listing
| Summary: | Implement references and declarations (aka "senders and implementors") | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Steve Northover <snorthov> |
| Component: | JS Tools | Assignee: | Michael Rennie <Michael_Rennie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | Carolyn_MacLeod, curtis.windatt.public, john.arthorne, libingw, Michael_Rennie, Silenio_Quarti |
| Version: | unspecified | ||
| Target Milestone: | 11.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 477995, 477999, 478219, 479064, 479068, 479085, 479155, 479177, 479775, 479780, 479812, 479813, 479814 | ||
| Bug Blocks: | |||
I changed the priority of this feature request to be P2 to indicate that I believe that this, along with refactoring, is one of a small number of critical features that IDEs provide. Thoughts? Giving to Eric because it's a mix of JS Tools and Editor. CC'ing Libing for possibly needed Search assistance. (In reply to Steve Northover from comment #1) > I changed the priority of this feature request to be P2 to indicate that I > believe that this, along with refactoring, is one of a small number of > critical features that IDEs provide. > > Thoughts? I agree, although a big problem I foresee is the same problem we have now with large workspaces - the file client will choke. Let me explain in pseudo-code-like-wordage. 1. choose member, run 'find refs' 2. search starts and we find match in foo.js 3. we have to infer foo.js for type checking 4. Tern resolves the dependencies in foo.js, we check types and carry on 5. repeat 1-4 ad nauseam until all done or run out of memory. Step (4) above will result in slow down as we end up building the complete graph for each potential match (unless more than one match is found in a given file, then the type information is cached). We could build partial, or no graphs, but then we lose a lot of type information, since almost no JS file is self contained (type-wise). The second biggest problem is making sure you have the correct type when you do find a match - my biggest worry here is that we will report too many or too few matches because type information is incomplete. What does Eclipse JSDT do? Does it offer References/Declarations search? (In reply to Carolyn MacLeod from comment #4) > What does Eclipse JSDT do? Does it offer References/Declarations search? To be honest, I have been trying to not ask that question - I try to ask "what does JDT do". In this case though, I checked, and JSDT doesn't seem to do anything unless the JSDT project is set up just so. Even once I set up the project (maybe correctly?) I could not find refs even in the same file. Why not do a "grep" search to find candidates, then for each candidate, compute tern information for the file? Of course, this could generate just larges a list. Can the tern information be computed when the guy clicks or lazily? If the "references search" can be cancelled and you get feedback while it is happening, the programmer can cancel it. If the programmer really needs to refactor every reference, then they really do need to compute the information. Can we implement something quickly and see how much time it would take? If I know that I will get a quality result when I search, I might be willing to consume the memory and/or wait. (In reply to Steve Northover from comment #6) > Why not do a "grep" search to find candidates, then for each candidate, > compute tern information for the file? Of course, this could generate just > larges a list. Can the tern information be computed when the guy clicks or > lazily? > That's what I was thinking. Then after the first pahse of simply finding matches we can use Tern to check each of them and assign weights like we do in content assist - 100 for very relevant, 50 for partially relevant, 1 for low relevance and 0 for no clue but same text > Can we implement something quickly and see how much time it would take? If > I know that I will get a quality result when I search, I might be willing to > consume the memory and/or wait. I am investigating the hooks to run a search from the JS tools now. Once I can run a search, hopefully I can hook into the search to post-process the results. The newer versions of Tern has support for 'refs' which will find type-matched occurrences across files that Tern knows about. This does not do a workspace/project-wide search like I am planning, but I implemented it anyway: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=87fa94ce5ba817af62f33cfb7124184c97fea9ad Sounds great! What is the scope of "files that Tern knows about"? (i.e. we may have to doc it if refs in workspace/project-wide scope aren't being found) (In reply to Carolyn MacLeod from comment #9) > Sounds great! What is the scope of "files that Tern knows about"? > (i.e. we may have to doc it if refs in workspace/project-wide scope aren't > being found) These would be files that you have opened at one time, or files that Tern has 'reached' from a dependency graph. The new handler / support is not hooked up to anything yet in UI because I still want to play with using search first + tern post-processing vs. having to stuff Tern full of unrelated files at the start and run a very long job. For example when testing the 'refs' request, I opened ternWorkerTests (a very large file), ran 'refs' and 5 minutes later Tern barfed, returning no results. I dark launched the command (the searching + UI is not available yet though) http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=6bcc31150ff4912b8e2062302fe9db12c93cba37 There is nothing to try yet. Let's get Libing involved. How do you make the feature available? etc. Please sort out with him so he can run the code. (In reply to Steve Northover from comment #12) > Let's get Libing involved. How do you make the feature available? etc. > Please sort out with him so he can run the code. Libing is involved. He has to sort out bug 475395, else there is no way for the JS bundle to interact with the the sidebar. I pushed a POC search pane for references, that I will likely have to move to client UI, along with the command decls for References > Workspace and References > Project. The reason being it all has to be added to org.eclipse.orion.client.ui/web/orion/sidebar.js. Here is the commit link: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=6f66e5379f001d4650f3bd6f5d6f557cfdf05af0 *** Bug 469844 has been marked as a duplicate of this bug. *** I pushed in the Tern hooks + the type request: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=711dc268d84d204e5fb45db9e27c71d325d4a5a6 Currently we have no problem finding the starting context (AST node), but finding the type is problematic, even more so when we successively start hammering Tern with type requests to check each match. Pushed changes that enables type-checked confidence tagging. I also added in a fall-back handler where I try to statically analyze a matches AST to measure confidence: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=831aefced9ed46c427b4cc51db69c044f247bc2f Currently the type checking that will give 100 confidence is measured on three points: 1. is the types name the same? 2. is the types kind the same? 3. is the types origin the same? If not all three of those match, I tag the match as irrelevant (we found a type for the match and it did not match our starting point). If however Tern cannot compute the type: there is no type at the location, or it fails for some other reason, I fall back to statically checking the AST myself. This involves a few steps: 1. if the match is part of a redeclaration, ignore it (confidence -1) 2. if the match is an id of a param, left or right hand side of an assignment expression (not a varibale declarator), callee name of a call expression or part of a member expression; give it very low conifdence 3. if the checker falls through from either 1 or 2, ignore it (confidence -1) There is much more work I can add to the static checks, like for new expressions and this expressions. Some blocking items: 1. the ui has to be incremental, this will always be long job and the first cut is an all-or-nothing operation 2. There needs to be a way to describe varying degrees of confidence vs. 100% or none. For example in some cases I give a confidence of 25% 3. Search results as shown are confusing for more than one on a line 4. performance / throttling needs to happen for asking Tern about match types - as it is now I just flood Tern with request after request, which sometimes can cause Tern to give up inferencing (when there are thousands of matches) We are looking to get to a clean point for Oct 15. There were a list of bugs that we have identified with Michael that need to be fixed. Also we need to have a scenario in place and ensure we work well for it. This means that 1) What are the list of bugs? Let's capture the list here 2) What is the code scenario? How about the ACE editor? We don't want to use Orion. (In reply to Steve Northover from comment #20) > We are looking to get to a clean point for Oct 15. There were a list of > bugs that we have identified with Michael that need to be fixed. Also we > need to have a scenario in place and ensure we work well for it. This means > that > > 1) What are the list of bugs? Let's capture the list here I linked all the bugs (we have so far) as blocking this one > 2) What is the code scenario? How about the ACE editor? We don't want to > use Orion. The basic scenario should be to select (or place the caret in) a javascript member (call expression, identifier or member expression), run the command and see all the categorized and weighted references to it. The hard scenario is to have the basic information be correct enough to be able to refactor the references without having to open any / all the editors for the refs. Bonus points to be able to decorate (or some other way note) references to show them as declarations and or implementations of the selected member. That would be cool. For example, comment matches that are not in JSDoc or substring matches list "xxxFooYYY" versus "xxxFoo". This has been un-darklaunched and is in general use, so I am going to close as fixed. The last two dependents can be fixed in due time, with new issues in their own bugs. |
Programmers continually make use of search in order to implement features and refactor their code base. Right now, Orion has 'Quick Search' and 'Global Search', neither of which make use of our JavaScript tooling to give better results. Some quick thoughts: References: For example, when I search for references to setXX(), I should never see setXXYY() in the list. I understand that there "setXXYY" could be just a field and might be assigned to the function setXX() somewhere in the code or that eval("setXX(12)") won't match etc. However, if I am the author of setXX(), I can know that if it is always called "normally" and use 'References' to find callers (preferably by just clicking on a call site and invoking a popup menu item) Declarations: When there are multiple implementations of a method (a function field in an object), I need to be able quickly search for them all so that I can see which code might run at a call site (also from a popup menu).