Community
Participate
Working Groups
I was using the multi-select quickfix to fix improper static references to IStatus in the org.eclipse.team.cvs.core plugin. Basically, we had a bunch of CVSStatus.WARNING references that should be IStatus.WARNING references. The multi-quickfix support made this easy but in one case, the substituted reference was wrong (i.e. it was CVIStatusARNING instead of IStatus.WARNING). I had a similar problem occur when I fixed CVSStatus.ERROR references.
Michael, do you have a test case for this. We had a discussion with Tod about multi applying quick fixes and the problem is that the problem markers have to be adjusted after every quick fix. This is not under control of JDT (so far). It has to be ensured by Platform/UI which actually "spins" the loop for the multi quick fixes.
OK, here is a test case: - take org.eclipse.team.cvs.core version I20051031 - enable compiler warning to warn about "Indirect access to static member" - open UpdateListener and focus problems view to the selected element - apply multi quick fix to the indirect access problems
I have tracked this down and the problem is that the JDT/UI infrastructure is getting out of sync with the content of the compilation unit. The current implementation brings the cached AST in sync using the reconcile. When the user requests quick fix through the editor, we make sure that the editor is reconciled hence we have an accurate AST. However, when we run the quick fix in a loop triggered by multi applying them the code still relies on reconcile to bring the AST in sync with the content of the CU. However automatic reconcile is trigger n ms (I think 500ms) after the last document change has occured. This means that some quick fixes compute their changes on an AST that doesn't match the content of the CU. Hence they compute textual changes at wrong positions (setting a breakpoint and interrupting the loop for some time produces the correct matches). As a side node: the problem already existed if the user changes the document and quickly enough (< 500 ms) triggered the quick fix from the problems view. JDT/Core has added API in M3 to broadcast the AST during reconcile. This will allow IMarkerResolutionGenerator to reconcile the CU which would bring the AST back in sync with the content. However using this new API is a bigger change which can demange a lot of other editor infrastructure. Aditionally I would like to discuss the consequences of such a change with Dani and Martin first. I therefore opt to disable the Multi Quick Fix support for M3 in Platform/UI again.
I would really hate to eliminate this feature in M3 - it is proving really popular. Would I would be willing to do is to put in a workaround in M3 for your issue to be resolved in M4. We could either add in a delay in recomputation or do something more interesting with a Job if this is possible at the UI level.
My impression with using multi-quickfix is that there were a lot of kinks that need to be worked out. In some cases I got the problem stated above and in others it failed part way through due to previous changes. I think it would be worthwhile investigating having explicit API that supports batching which would eliminate both types of failures. Having said that, neither failure was so drastic that I would suggest disabling the feature. It is possible that this failure could result in code that was wrong but compiled and this would be a major problem but I think this is highly unlikely. Perhaps we should popup a warning in M3 that states that this feature is a work-in-progress and users should inpsect all changes to make sure they are correct (tha's what I did when I committed the fixes).
IMO such a dialog will scare users (and will give the impression of a "half baked feature"). Regarding how likely it is that this occurs: it will happen if two quick fixes touch the same CU and the quick fix applied second changes code after code touched by the first quick fix. If you look at the new Clean Up action (available from source) we added for M3 you can see that we invested a lot for being able to multi apply quick fixes and we had to tweak every quick fix that is currently supported. The problem is not only to sync the AST with the CU. One of the major changes was that we are able to reuse a created AST and that we detect case where both manipulate the same textual region. Multi Quick fix will otherwise simply not scale. So I am more in favour to disable for M3 and come up with a better API for M4 to support applying multiple quick fixes. We can leverage and learn form the work that Benno has done in JDT/UI during M3.
IMO it is a bug of the new UI in how it uses the marker resolution extension point. It collects all the proposal first, but applies some of them after some other changes have been made. The JDT UI quick fixes could be changed to handle that, but I suspect that many other contributed resolutions will fail. - Executing a quick fix might influence the fix for a second problem in the same file. It might even make the fix unnecessary. -> After executing a fix, you platform UI should request the fix for the next problem again) - The action to fix more than one problem might be different than the fix for one problem (see bug 111571)
I agree Martin - you can't move on this until I have resolved Bug 114754
moving to platform.ui.
Martin how do you want me to resolve this - as a dup of Bug 114754? This is going to be obsolete when Bug 114754 is done - I can open one about you using the new mechanism then.
Sure, mark it as dup of Bug 114754.
*** This bug has been marked as a duplicate of 114754 ***
