Community
Participate
Working Groups
Thas was introduced with M6. You can argue the sanity of this code, but the org.eclipse.cdt.core plugin has an interface ICSearchConstants that has two inner classes defined like this: public class SearchFor{ private SearchFor( int value ) { this.value = value; } private final int value; } public class LimitTo { private LimitTo( int value ) { this.value = value; } private final int value; } I am getting a compile error in a sub-interface ICSearchPattern when LimitTo is used as a parameter: boolean canAccept( LimitTo limit ); Everywhere else seems to be fine with it. You can check out the org.eclipse.cdt.core plugin from /cvsroot/tools/org.eclipse.cdt-core. This code now only exists on the cdt_3_0 branch.
Could you please provide a complete test case? I tried with N0417 and it worked fine. Closing as REMIND. Please reopen when the requested information is available.
Reproduced checking out the branch 3_0 of the cdt-core plugin.
Kent, This fails during the first full build, but if you modify the contents of the ICSearchPattern interface and recompiles, the error is gone. I tried to reduce the test case, but I could not get a test case that reproduces the failure once isolated.
If I compile using only the batch compiler (and the ant script), I cannot reproduce.
It seems to be related to the position of the ISearchConstants and ICSearchPattern interfaces in the build process. If the two interfaces are compiled after all other types, it fails. But if I insert them at the beginning of the compilation process, it succeeds.
This was a heck of a bug! We used a tagBit to temporarily mark interfaces while we walked the hierarchy of a type in case it contained multiple references to the same interface, then cleared the bit at the end of the loop. The problem was we used the same bit in other places for the same purpose and after marking an interface ICSearchPattern, we ended up resolving a method of ICSearchConstants which contained a reference to a member type of ICSearchPattern. Well findMemberType() also used the bit to walk the hierarchy to find inherited member types. This bug has been around for a long time but is very order dependent. The affected types needed to be compiled in a very specific order for the bug to happen. I've thrown away the bit and we're now using SimpleSets to hold onto the interfaces that we've seen.
Excellent! I'll give it a try when RC2 comes out. Thanks.
Moved org.eclipse.jdt.internal.core.util.SimpleSet into org.eclipse.jdt.internal.compiler.util.SimpleSet. Otherwise this introduces a dependency on the compiler on the model classes.
Kent - where is the regression test ?
Had no luck reducing this case to a smaller testcase. To test, compile the org.eclipse.cdt.core plugin from the cdt_3_0 branch in /cvsroot/tools/org.eclipse.cdt-core
I reverted Scope to what it was before the change (keeping MethodVerifier change), and wasn't able to reproduce the issue in CDT.
Excellent. CDT 3.0.x now compiles. Thanks!
