Community
Participate
Working Groups
I ran into a problem trying to add unimplemented methods to a class that implements an interface. There were three methods but one of them has a dependency on a plugin that was not in the dependencies of the project. Using the code assist (CTRL-1) "Add unimplemented methods" added 2 of the methods but not he third. Hence the error stayed around but the error about a dependency problem never appeared. This may be because I didn't save the file but I could keep trying "Add unimplemented methods" and nothing would happen. In the very least, a prompt or some other strong indication of what went wrong should be given to the user.
>using the code assist (CTRL-1) This is Quick Fix. Code Assist is Ctrl+Space and if you press Ctrl+1 while there's no error or warning it's calles Quick Assist ;-)
Just to clarify the scenario: 1. interface I in project B with three methods that compile correctly, one of those methods depends on project A. A is marked as required by B. 2. have class C in project C which only marks B as required There are three problems here: 1. JDT Core does not detect that I is not valid as interface for C: - code assist suggests it - no problems are generated for that setup 2. "Add unimplemented methods" only adds 2 (and 0 afterwards) methods without any hint to the user 3. After adding the two methods JDT Core does not report the temporary problem about the missing method any longer until I save and I get the error marker due to auto-build. Moving to JDT Core re: 1 and 3. The second problem might be a follow-up of the first one. Adding Martin to comment about.
3.2 M6. I stumbled across the same issue while following some steps from the Eclipse Help (implementing an extension). Thus, I entered the class name and used the new class wizard offered by the manifest editor to create the implementation stup. The class extends org.eclipse.jface.wizard.Wizard and implements org.eclipse.team.ui.IConfigurationWizard. Inherit abstract methods was selected but the generated class only contained the performFinish method stub from the Wizard class. An error was generated indicating the the class must implement the inherited abstract method from IConfigurationWizard. I tried to use the QuickFix for this but it actually did nothing. The hover info said "0 method(s) to implement". I also tried to use the Content Assist but it didn't offer to overwrite the method. The problem is that IConfigurationWizard requires IProject on the build path but I didn't have the Resources plug-in on the build path yet.
re 1: - Code assist can not filter these kind of types because it would be too costly to filter it. It would require to compute bindings for all proposed types. re 2: - One method is missing because this method cannot be fully resolved. So this method is removed from the type binding during resolution. re 3: - The problem seems to be located in MethodVerifer but i am not sure because i am not familiar with this code.
Maxime, It might be worth investigating issue 3 in comment 2.
Maxime, pls assess behavior considering planned fix for bug 114349
Reproduced using R3_2_maintenance.
The patch suggested by https://bugs.eclipse.org/bugs/attachment.cgi?id=51996 does not change the observable behavior at all. Will dig deeper relatively to comment 2, item 3 with and without the patch.
At the time we check if more methods must be implemented, typically within MethodVerifier15#checkMethods, the inherit methods list won't contain the faulty method at all. Hence the observed behavior. When the next build comes into play, the inherited methods do include the faulty method. The issue must lie in different ways to build the inherited methods list depending on whether we are in build or in reconcile. When we reconcile, SourceTypeBinding#resolveTypesFor(MethodBindind) explicitly nullifies the method binding if we have a problem when resolving parameters types. The method thus 'disappears' from the type for subsequent checks. Two paths to investigate: a) adopt a different way to hydrate bindings in that scenario, in order not to suppress the faulty binding; would start by looking at what happens in the build scenario; b) consider not nullifying the faulty binding but using an explicit faulty binding value instead, in the same spirit as bug 114349 does with types. Path b would probably demand more extensive changes.
Added ReconcilerTests#test1001 (inactive) and 1002.
Created attachment 53467 [details] Experimentation - do not release This patch makes an experiment in which what SourceTypeBinding#resolveTypesFor does for parameters unresolved types is more in line with what it does in case the return type is unresolved. Since we do not have a class to implement unresolved types yet (waiting for bug 114349) this experiment merely uses TypeBinding.INT instead - which cannot be considered to be a fix for the problem. But it gives a good signal about using this technique to solve the issue after bug 114349 is fixed. Will run a full test to detect other potential consequences.
Looks promising enough. Waiting for bug 114349 release.
Created attachment 54770 [details] Experimental fix + some test cases modifications This experimental fix builds upon (and includes) the latest patch as of today for bug 114349(https://bugs.eclipse.org/bugs/attachment.cgi?id=53615&action=view). It shows that the approach fixes the initial problem. We do have ripple effects across the other tests due to the fact that method bindings with problem parameters are now returned instead of null in such cases. The existing code already did that for problem return types. Further investigations should decide: - if we want to return non null bindings for methods which have problem types for some of their parameters; - if we fix the test cases or the code for failing tests; - assuming that we fix the code, whether or not we explicitly tag those methods as having problems, and how.
Due to the dependency on 114349 and the need to work on ripple effects, will not make it for M4.
Bug 114349 has been released but, as of today, we still get a null type reference back for X in the test case (instead of some form of MissingBinaryTypeBinding). We could create one ourselves... but for the cases where the error has another cause and nature. I will raise the case for an error management policy that would keep more information at hand and will see where we can go from there.
After discussing the matter with Philippe, we came to the conclusion that we would not fix this bug. The current policy for type errors is to raise a problem type when the type cannot be resolved. One of the callers emits an error and returns null, so that: others know the error has been reported; recursions and loops get ended. Following the same pattern, the bindings that depend on unresolved types get simplified (as is the case for methods which parameters types cannot be resolved) or nullified. Making an exception for the sole case of an unresolved binary type for parameters would make incremental builds more different from full builds than needed. (In the case of a full build on sources only, Philippe contends that the resulting unresolved type is much more error prone than in the case it would come from binaries - the reason being that binary types have a complete signature that enables us to rebuild the qualified name, whereas a simple name in a source file that also includes automatic imports may match many a type.) It is felt that breaking that isolation layer for the current case only has an unfavorable cost/benefit ratio, hence we won't fix this bug. Note: I have activated ReconcilerTests#1001 to watch the behavior on this case, keeping the desired behavior in comment.
Should the UI indicate an error in the case? The current behavior is somewhat odd, i.e. you execute the Quick Fix and nothing happens. No error is reported, nothing. Actually, it looks like Eclipse is not working as expected although it is. I remember that it took me quite a few minutes before I got to the classpath reason that the QuickFix is not working. I'm wondering how long an unexperienced Eclipse user would need to discover this bug.
