Author Topic: Go To Definition (CTRL+.) does not work sometimes  (Read 2505 times)

mychong

  • Community Member
  • Posts: 46
  • Hero Points: 0
Go To Definition (CTRL+.) does not work sometimes
« on: January 19, 2016, 01:24:32 am »
Go To Definition (CTRL+.) does not work sometimes. It brought me to the function prototypes in the header files instead of the function definitions in the .cpp files. I am using VS20.0.1.3 (both Windows & Linux versions). I saw someone mentioned about this problem a few years back, but apparently this problem remain not fixed even today.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3035
  • Hero Points: 446
Re: Go To Definition (CTRL+.) does not work sometimes
« Reply #1 on: January 19, 2016, 05:28:37 pm »
You are going to have to post an example.  If I were to guess, you probably have preprocessing in the code that is interfering with the tagging parser.  There is also an option for Ctrl+. to navigate directly to prototypes, if you are using that setting, you would need to hit Ctrl+. again (as suggested by the messages on the status line) to continue to the implementation.

mychong

  • Community Member
  • Posts: 46
  • Hero Points: 0
Re: Go To Definition (CTRL+.) does not work sometimes
« Reply #2 on: January 20, 2016, 12:41:35 am »
I have tried all the 3 options for "Prioritize navigation to":
o Prompt with all choices (current settings)
o Symbol definition (proc)
o Symbol declaration (proto)
None of these help when clicking on certain functions in my project files. It always go to the function prototypes. It does not even prompt me with all choices like some other functions in the same project.  I am sure that all the affected function declarations are included in the project list.
Sorry, I cannot post those files here since they are proprietary and confidential to my company.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3035
  • Hero Points: 446
Re: Go To Definition (CTRL+.) does not work sometimes
« Reply #3 on: January 20, 2016, 01:14:52 am »
Can you mock up an example based on the structure of your code, of obfuscate a small portion of the code to create an example?

Your first step for fixing the problem yourself is to rebuild your workspace tag file, just to make sure that it had not been corrupted and is not out of date (Project > Rebuild Workspace Tag File...).

Next step is to open the file that you expect the function definitions to be in and look at the Defs tool window (sort by line number).  Verify that the functions show up with the correct names (and class and namespace scopes).  If they don't, you probably need to trace up the file to the last thing that was recognized the way you expect it.  The scour the code from there for the preprocessing, or whatever other nastiness is causing subsequent code not to parse.

mychong

  • Community Member
  • Posts: 46
  • Hero Points: 0
Re: Go To Definition (CTRL+.) does not work sometimes
« Reply #4 on: January 20, 2016, 02:06:34 am »
Retag workspace under the 3 different "Prioritize navigation to" options, but to no success.
Looked under the Defs tool window and the function name was listed correctly.
Finally, I mocked up a simple example to illustrate my problem. This sample project consists of 3 files, and are as shown below:

// start of "main.c"
#include "func.h"
int main(void)
{
    f1();
    f2();
    f3();
    return 0;
}
// end of "main.c"
// start of "func.c"
void f1(void)
{
    return;
}
static inline void f2(void)
{
    return;
}
inline void f3(void)
{
    return;
}
// end of "func.c"
// start of "func.h"
void f1(void);
static inline void f2(void);
inline void f3(void);
// end of "func.h"

"CTRL+." on f1() and f3() would always prompt me with choices of proc or proto.  However, "CTRL+." on f2() would always end up in the function prototype in the header file "func.h".  It seems to me the culprit is the keyword "static".

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3035
  • Hero Points: 446
Re: Go To Definition (CTRL+.) does not work sometimes
« Reply #5 on: January 20, 2016, 04:41:20 pm »
SlickEdit is handling your example code the way the language standard specifies.  One hint is the fact that the example does not link (see errors).  "f2" is static to func.c, so it should not be visible to main.c.  "f3" is declared inline, so again, main.c will not be able to link to it.

Code: [Select]
---------- 'build' Project: 'mychongexample.vpj' - 'Debug' ---------- func.c
main.c
In file included from main.c:2:
./func.h:3:20: warning: function 'f2' has internal linkage but is not defined [-Wundefined-internal]
static inline void f2(void);
                   ^
main.c:6:5: note: used here
    f2();
    ^
In file included from main.c:2:
./func.h:4:13: warning: inline function 'f3' is not defined [-Wundefined-inline]
inline void f3(void);
            ^
main.c:7:5: note: used here
    f3();
    ^
2 warnings generated.
Linking...
Undefined symbols for architecture x86_64:
  "f3()", referenced from:
      _main in main.o
  "f2()", referenced from:
      _main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
*** Errors occurred during this build ***

My suggestion would be to remove the "static inline" from f2 and the "inline" from f3, since you are not actually using either function as such.

If fixing the code is not an option, and your build system lets you in fact can get away with using static and inline in this manner throughout your code base, I would suggest adding "static" to your C/C++ Preprocessing (Document > C/C++ Options... > C/C++ Preprocessing) so that our parser can ignore the incorrect usage of static in the code base.

mychong

  • Community Member
  • Posts: 46
  • Hero Points: 0
Re: Go To Definition (CTRL+.) does not work sometimes
« Reply #6 on: January 21, 2016, 12:33:26 am »
Changing the code is not an option as this part of the code is written by other team members and the build system can compile and link without problem.

Nonetheless, your suggestion to add "static" to the C/C++ Processing works.

Thank you for your great support.  This case is considered close.