Bugzilla – Full Text Bug Listing
| Summary: | project linked resource filter not being applied during source lookup | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Kirk Beitz <kirk.beitz> |
| Component: | cdt-debug | Assignee: | cdt-debug-inbox <cdt-debug-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | Ken Ryall <ken.ryall> |
| Severity: | normal | ||
| Priority: | P3 | CC: | jamesblackburn+eclipse, pawel.1.piech |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows All | ||
| Whiteboard: | |||
since i started running Helios SR1 / cdt 7.0.1 , the symptom of not being able to intersperse DSF-GDB has gone away. in looking at the source of the location i recommended, serge beauchamp made a fix to use the Alias-manager there, where that would do a better job of resolving linked resources. therefore, i'm going to mark this issue resolved as a duplicate of that issue (even it's really a side-effect). *** This bug has been marked as a duplicate of bug 321892 *** Actually likely a duplicate of bug 317783 which has been fixed both in CDT and Platform. *** This bug has been marked as a duplicate of bug 317783 *** |
there's a location deep in a call from DSF-GDB disassembly with roots in org.eclipse.cdt.core/sourc/org.eclipse.coreorg.eclipse.core.internal.localstore from my eclipse-3.6\plugins\org.eclipse.core.resources_3.6.0.v20100526-0737.jar that appears to be skipping the step of applying resource filters to resources containing files that get referred to and looked up by the debugger. my best guess at the best candidate location for a fix would be at about line 109 in FileSystemResourceManager#allPathsForLocationNonCanonical() (based mostly on the stack-crawl at the bottom of this description). context: (1) having imported HelloWorld project ... (2) created linked resources for it include -> ..\..\..\workspace\org.ecl...edc.tests\resources\Projects\BlackFlag\src Source -> ..\..\..\workspace\org.ecl...edc.tests\resources\Projects\BlackFlag\src (notice that each resource points at the same location). (3) each resource has its own filter. include -> *.h Source -> *.cpp behavior: - with a setup as above, DSF-GDB debugger will not intersperse source at the location i mentioned above, if i force the resource to be null at the proper point, causing it to skip the "include" folder and get to the "Source" folder, then the upper-level caller is happy, and source gets interspersed properly for any resource for which i've done this. it also seems possible that filterChildren(IFileInfo[],...) could be called . perhaps it could be called at the location i mentioned above, or perhaps a bit further down in the stack below. the following stack shows the path from the job started by DSF-GDB disassembly down into the location where i believe the resource filters should be applied. Project(Container).findMember(IPath, boolean) line: 124 Project(Container).findMember(IPath) line: 117 FileSystemResourceManager.allPathsForLocationNonCanonical(URI) line: 99 FileSystemResourceManager.allPathsForLocation(URI) line: 57 FileSystemResourceManager.allResourcesFor(URI, boolean, int) line: 166 WorkspaceRoot.findFilesForLocationURI(URI, int) line: 112 WorkspaceRoot.findFilesForLocationURI(URI) line: 103 FolderSourceContainer(ContainerSourceContainer).findSourceElements(String) line: 108 ProjectSourceContainer(ContainerSourceContainer).findSourceElements(String) line: 124 DefaultSourceContainer(CompositeSourceContainer).findSourceElements(String, ISourceContainer[]) line: 79 DefaultSourceContainer(CompositeSourceContainer).findSourceElements(String) line: 46 CSourceLookupParticipant(AbstractSourceLookupParticipant).findSourceElements(Object) line: 67 CSourceLookupParticipant.findSourceElements(Object) line: 118 AbstractSourceLookupDirector$SourceLookupQuery.run() line: 141 SafeRunner.run(ISafeRunnable) line: 42 DsfSourceLookupDirector(AbstractSourceLookupDirector).findSourceElements(Object) line: 742