Community
Participate
Working Groups
M2 See test cases AllTypesCacheTest.testWorkingCopies() & testWorkingCopies2(): Editor is opened and the type name of the opened type is modfied. testWorkingCopies(): editor is saved: new type is found in index but also old type is still found testWorkingCopies2(): editor is not saved: new type is not found in index
Fixed SearchEngine.searchAllTypeNames(...) to filter out results from indexes that have a corresponding working copy, and add the types of the working copies at the end. Added regression test WorkingCopySearchTests.testAllTypeNames() Also note that the tests in AllTypesCacheTest need to be changed to reset 'res1' before doing the second query.
20030916 (jdt.core v_370) The test 'testWorkingCopies2' still fails: The new type 'A' is not found. (fixed the missing 'res1.clear))
Just ran 'testWorkingCopies2' from org.eclipse.jdt.ui.tests v20030916 and it passed. Do you have more details on how to make it fail?
Did you set JavaPlugin.USE_WORKING_COPY_OWNERS to true?
No, it wasn't in the instructions :-)
AllTypesCacheTest.testWorkingCopies() & testWorkingCopies2() from v20030916 still don't clear 'res1'
After fixing the tests, they pass under the debugger, but testWorkingCopies2() fails when run full speed. Sounds like a timing issue. Martin are you sure that the working copy has been reconciled when asking for all types?
'res1.clear()' is in v20030923 or HEAD!
Comment #2 said 20030916 !!! And you didn't answer my last question.
Didn't know that I have to reconcile before searching. What's the rule here? Before every search all CU that are in working copy mode have to be reconciled? Couldn't search do that if it really needs that?
This is the same rule as for the Outline: it shows new types only after a reconcile. It is not the job of the SearchEngine to do so.
Note that the reconcile is usually done automatically by the Outline view. You need to force the reconcile only in the tests.
Sorry for the confusion about versions. It was supposed to describe what jdt.core I was using. Always take HEAD of the tests and our code. About the reconcile: If you want me to do this; is there method that returns all CU currently in working copy mode so I can make sure that each is reconciled? I really think search should do that when called. Why would I want to search on on an outdated structure? The outliner of course reconciles every 300 ms, but in the event of a search I want the most current state, not even the one 100ms before!
If we took HEAD for your tests, we would have to take HEAD for jdt.ui, and HEAD for platform.ui, etc... We have to concentrate on jdt.core. Moreover we run the jdt.ui tests from last integration build to make sure that we don't break you, but these should not be seen as test cases. A good test case from the jdt.core point of view is a test case that uses jdt.core API only. Otherwise we have to spend time understanding your code. We have enough on our plate with jdt.core already.
As for reconciling working copies, we would have to do it for each operation (e.g. ICompilationUnit.getAllTypes()), which would be expensive especially in the case of no changes to the underlying document. I expect that jdt.ui and/or jdt.text know when a change to the underlying document has occured, so when it is a good time to reconcile. That's actually the whole purpose of the reconcile operation.
I see the problems with having everything in HEAD. I agree that's a pain. It seems to work fine with Olivier. I send him test case like that all the time. So in today's integration build you have all the tests as I mentioned them in the bug reports. I though it's clear that when I mention a version number this would be one of the past. I guess if you don't like HEAD, you have to wait for the next integration build. Or maybe use the nightly build? As for reconciling working copies: There are usually many editors open, all of them in working copy mode, potentially unsaved. So if you don't want to force them to be reconciled: We would have to do exacltly the same. So performance- wise this comes to the same. We don't know either if a CU has been reconciled after the latest change. To avoid unnecessary reconciles on unmodified document you probably need a dirty bit for that. I don't think we should have such a dirty bit. In my opinuon it is a implementation detail that type search uses the Java Model elements. It could also use the AST and in that case a reconcile wouldn't be necessary. And if a reconcile is required, you have to document it.
Will use the working copy if it is consistent with its buffer, otherwise will do the search by reparsing the buffer's source, without reconciling the working copy. This should make everyone happy.
I don't think Olivier would agree that working with HEAD from another plugin is confortable :-)
Ok, we will ensure search find matches in non-reconciled working copies. Ideally, we want to avoid forcing a reconciliation action since it will notify clients in an unexpected way. We should only use the model if consistent, if not then we should consider the buffer contents (and parse it) directly. This would be consistent with various resolve actions (which directly look at the buffer).
Even after changing the SearchEngine to take the buffer's content instead of the working copy, the test still fails. Problem is that the AllTypeCache relies on Java delta to mark itself as needing refreh. This can happen only if the working copy has been reconciled. IBuffer.setContent(...) doesn't force a reconcile. So even if we forced a reconcile in the SearchEngine, AllTypeCache would not call the SearchEngine since it considers it is up-to-date.
Have to think about that. I think this means that the AllTypeCache should force a reconcile to be sure it got all the deltas. I'll look at that. Thanks for the fix for search. Please release it still, I think it is the correct thing to do.
Released the fix in SearchEngine. Will not be in I20030924, but in next integration build.
JDT/Core side of the problem is fixed. A new bug is being opened against JDT/UI for the AllTypeCache needing to reconcile its working copies.
New bug in JDT/UI is bug 43641.
Verified.
