NEW DATE! Bugzilla will undergo maintenance 2024-03-28 18h00 CET. Bugzilla will be placed in read-only mode at that time.

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 525739 - Definition-to-declaration navigation works in spite of signature mismatch, but not vice versa
Summary: Definition-to-declaration navigation works in spite of signature mismatch, bu...
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-source-nav (show other bugs)
Version: Next   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 9.5.0   Edit
Assignee: Nathan Ridge CLA
QA Contact: Doug Schaefer CLA
URL:
Whiteboard:
Keywords:
: 434680 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-10-09 03:48 EDT by Nathan Ridge CLA
Modified: 2017-12-20 16:02 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Ridge CLA 2017-10-09 03:48:20 EDT
In the following code:

  class Waldo {
      void find();
  };

  int Waldo::find() {}

there is a signature mismatch between the declaration and the definition of Waldo::find().

In spite of the mismatch, Open Declaration on the definition takes you to the declaration.

The reverse is not true: Open Declaration on the declaration does not take you to the definition.

It would be nice if the latter worked as well, as it would support the following common pattern:

  - You want to modify the signature of a method
  - You start by modifying the signature in the header file,
    thus introducing a (temporary) signature mismatch
  - You now want to quickly navigate to the definition to
    make the corresponding adjustment
Comment 1 Nathan Ridge CLA 2017-10-11 00:53:44 EDT
Fixing this is somewhat involved.

For a method, the declaration is considered the source of truth, so when there is a mismatch between the declaration and the definition, the definition resolves to a ProblemBinding, while the declaration resolves to a normal binding.

Navigation from the definition to the declaration works, because the ProblemBinding for the definition has all methods with a matching name as candidate bindings, and for a name that resolves to a ProblemBinding, Open Declaration searches for the declarations of the candidate bindings.

The reverse search is more involved: given a name that resolves to a regular binding, we have to find all definition names that resolve to a ProblemBinding which has our binding as a candidate.

For a method defined in the same file as the declaration, that's relatively straightforward, because we search the AST "on the spot" for such definitions, and so it's just a matter of adjusting the search to be slightly more permissive.

For a method defined in a different file, however, we just query binding <-> definition relationships that were recorded at indexing time. Currently, we don't record any relationship between a name that resolves to a ProblemBinding, and the ProblemBinding's candidate bindings (in fact, we do not store names that resolve to problem bindings in the index at all). We would have to start storing such names and recording their relationships to their candidate bindings, annotate the relationships as being "potential" / "fuzzy" / whatever, and adjust relevant index APIs to consider or not consider such relationships as appropriate.
Comment 2 Nathan Ridge CLA 2017-10-11 00:58:43 EDT
(In reply to Nathan Ridge from comment #1)
> Currently, we
> don't record any relationship between a name that resolves to a
> ProblemBinding, and the ProblemBinding's candidate bindings (in fact, we do
> not store names that resolve to problem bindings in the index at all). We
> would have to start storing such names and recording their relationships to
> their candidate bindings, annotate the relationships as being "potential" /
> "fuzzy" / whatever, and adjust relevant index APIs to consider or not
> consider such relationships as appropriate.

On the other hand, doing this would open the door to other useful navigation enhancements. 

For example, you often want to change the signature of a function that already has call sites. You often end up doing it in this order:

  1. Change the declaration / definition
  2. Change the call sites

The problem is, after you've done (1), Find References no longer finds the call sites, so you have to remember to do the search before doing (1). 

What I described above would allow us to, after doing (1), still offer the no-longer-exactly-matching call sites as potential matches in such a search.
Comment 3 Eclipse Genie CLA 2017-10-11 01:06:42 EDT
New Gerrit change created: https://git.eclipse.org/r/106548
Comment 4 Nathan Ridge CLA 2017-10-11 01:08:36 EDT
(In reply to Eclipse Genie from comment #3)
> New Gerrit change created: https://git.eclipse.org/r/106548

This is the beginnings of an implementation of the approach described in comment 1, but it needs a fair bit of more work, as described in the commit message.

I don't have time to finish it now, but I may return to it later. If someone else would like to pick it up in the meantime, please feel free!
Comment 5 Nathan Ridge CLA 2017-10-16 17:25:46 EDT
*** Bug 434680 has been marked as a duplicate of this bug. ***
Comment 6 Nathan Ridge CLA 2017-12-12 14:16:40 EST
I finished this patch off (see update to Gerrit change).
Comment 8 Nathan Ridge CLA 2017-12-20 16:02:26 EST
Fixed for 9.5.