Community
Participate
Working Groups
When launching a GDB sessions, two instances of DsfSourceLookupParticipant are created, one by the DsfSourceDisplayAdapter (which is part of the Adapter set) and one by DsfSourceLookupDirector (as part of initializeParticipants in DsfSourceLookupDirector, created during the launch delegate launching process). When a source file is not found, or when search for duplicates is on, both the instances are queried for source files. In the PDA example, the PDASourceLookupDirector explicitly (with a comment) does not create a DsfSourceLookupParticipant. So in the PDA example there is not a duplicate. Neither of these bits of code have been changed since migrating DSF and DSF-GDB to the CDT project. This has become a bug as part of the work for Bug 472765 because it is important in that case to use the specialized version of the source director and in that case the DsfSourceDisplayAdapter's creation is problematic.
New Gerrit change created: https://git.eclipse.org/r/63286
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/63286 This has been abandoned for now, but it would be nice to reconsider this in the future again. Perhaps when there is not so much churn, or perhaps a different version of the patch (e.g. add it in in DsfSourceDisplayAdapter unless there is already a participant in).
(In reply to Jonah Graham from comment #2) > (In reply to Eclipse Genie from comment #1) > > New Gerrit change created: https://git.eclipse.org/r/63286 > > This has been abandoned for now, but it would be nice to reconsider this in > the future again. Perhaps when there is not so much churn, or perhaps a > different version of the patch (e.g. add it in in DsfSourceDisplayAdapter > unless there is already a participant in). Just to clarify why we abandoned this change for now. I was worried that removing the default DsfSourceLookupParticipant could break existing DSF extenders. I thought such a breakage would also be difficult to chase down. As Jonah confirmed that there is no issue besides inefficiency in having two participants, I recommended be more careful approach. Note that we've had more than one such participants from the very start (apparently we had 3 of them).
