Community
Participate
Working Groups
Created attachment 250380 [details] Inconsistent hierarchy, but no clue where the problem is. When working with more and more projects and also moving them around, factoring them out or collapsing some, one increasingly runs into inconsistent object hierarchy failures (as shown in the attachment). The more projects one has, the more difficult it gets to see what exactly is wrong --- although of course the hierarchy consistence checker knows pretty well what went wrong (or it couldn't tell there's something wrong in the first place), it does not show any of that information. Please consider adding more information to the "hierarchy of ... inconsistent" message.
Hmm.. I agree this creates trouble at times. Only way I can think of providing more information is when the HierarchyHasProblems bit is set, but dumping debug info while doing the resolution is not something we re keen on doing. I am not saying we can't do this, but at the moment I don't have a good way. Suggestions are welcome.
I don't know the internals of the checking process, but in some cases I get an error marker on the first line of the source file, which says something in the line of “Class path.to.XY is not in the hierarchy”, and I am offered “Modify build path...” as sole option. This looks pretty much as the solution to me. As I don't know how to produce this case, I will add it later to this bug report once I encounter it again. It doesn't actually matter how many inconsistencies there are at any time — reporting one of them already helps, because this way I can handle one issue, save and rebuild, handle the next issue, save and rebuild, a.s.o. until all issues are gone.
Created attachment 250596 [details] The case I mentionned looks like this (screenshot)
Is this a problem of distance between the code where we detect a problem (and set HierarchyHasProblems) and the code that reports the error? One option might be, to pass a scope or a problemReporter down the line, so we can report right when it is detected. This might, however, trigger a flood of secondary errors. I gather that the current approach is meant to collect different sources of inconsistency in order to report only once. Next option would be to remember more than just the one bit HierarchyHasProblems, perhaps we could indeed create a DefaultProblem, without yet reporting it, though. Then the site that does the reporting can retrieve the previously constructed DefaultProblem(s) and use that for more detailed reporting. This would call for a new field, perhaps in ReferenceBinding.
(In reply to Stephan Herrmann from comment #4) > Is this a problem of distance between the code where we detect a problem > (and set HierarchyHasProblems) and the code that reports the error? > > One option might be, to pass a scope or a problemReporter down the line, so > we can report right when it is detected. This might, however, trigger a > flood of secondary errors. I gather that the current approach is meant to > collect different sources of inconsistency in order to report only once. I was trying out this and found the secondary errors to be a problem we may not be able to overcome in all scenarios. > Next option would be to remember more than just the one bit > HierarchyHasProblems, perhaps we could indeed create a DefaultProblem, > without yet reporting it, though. Then the site that does the reporting can > retrieve the previously constructed DefaultProblem(s) and use that for more > detailed reporting. This would call for a new field, perhaps in > ReferenceBinding. This sounds interesting to me. Will try this out. Or anyone interested in taking a shot?
But sometimes it just works perfectly as it should (see new screenshot) — the mystery is: WHEN?
Created attachment 250803 [details] When it really serves its purpose … Sometimes it just works perfectly …
Created attachment 250826 [details] A special case with unresolved recursive dependencies leading the wrong way And here is one very strange looking case. Apparently I forgot to add my XML projects to the build path, and since both Information.class and BasicInformation.class come from different projects (one interface project and one implementation project) and refer to the XML project as well, the current project finds two apparently independent unresolved dependencies, which makes it think the two types are incompatible—which they aren't. This is wrong reasoning (it goes too far: two unresolved types with the same class name usually refer to the same object class, even when found in different projects). To resolve the conflict, the checker should see that the current project misses a resource that is referred to from both already present dependencies. An even better solution would be to introduce recursive dependencies and automatically load dependencies of dependencies to the build path. A somewhat less reliable solution could be to "induce" dependencies of dependencies without the need to actually place them into the build path, but that would be less flexible.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Still a relevant request, just so far nobody in the team has found the time => helpwanted.
