SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: joecar on February 09, 2021, 06:47:48 PM
-
hotfix_se2501_1_cumulative
When I do Goto Reference from a usage, the Reference pane shows only that usage. What am I doing wrong?
When I do Goto Reference from the declaration/definition, the Reference pane shows all instances (declaration/definition and usages).
Thanks.
-
Filter is set to show all tags.
-
Can you put together a small example I could reproduce that with? Also, make sure "Look in:" is not set to "<Current File>"
-
"Look in:" is set to "<Current Workspace>".
As I put together small examples for you, they seem to work properly... ::)
-
It also happens when "Look in" is set to "<All Open Files>"
and the files containing the declarations/definitions are open.
-
Here is a pic (I had to obfuscate the details), see attached.
I'm still working on a simple example that shows the problem.
-
It appears that the definition is "static inline" but in a separate file. Is that correct? What is the file extension on that file? We do have a special case to treat static functions in a ".h*" file as an extern function, but otherwise, a static definition is limited to the scope of the module it is declared in.
Some folks have suggested working around this by defining a preprocessor macro like #define STATIC_IN_HEADER static, which I can declare to SlickEdit as an empty #define in the C/C++ Proprocessor setup, and using that instead of using the static keyword directly in header files.
-
Thanks.
That static inline is in the same file at line 748 (see Search Results pane in pic posted above), and is referenced at lines 916, 932, 956.
It is happening regardless of inline, and in the same or other files, but not for all cases.
I'm still working on a suitable simple example to show this behaviour.
-
I should have said files are .c or .h.
Also note:
Goto Definition and Goto Declaration work ok.
Goto References from definition/declaration works ok (shows all instances/usages).
-
The good news for a case like that is it appears to be restricted to that single file. In fact, if you opened SlickEdit with a default configuration and the opened just that file, hopefully, you would get the same result. Then all you need to do is whittle that file down to the bare bones and rename and/or obfuscate the rest.
You could try the attached macro (which I will add to SlickEdit for 25.0.2) to do the obfuscation.
-
. . .
More info:
When the usage assigns the return value to a variable, Goto References works properly.
When the usage does not assign the return value, Goto Refrences shows only the usage.
I have found this, but I have also found cases where this does not matter.
-
Obfuscated file attached.
Look for function sL60C().
Doing Goto References from line 738 produces 4 references.
Doing Goto References from lines 877, 891, 911 produces only 1 reference.
In this case, the function is defined within the same file as its usages (there are cases where this is not so).
-
BTW: Thanks for the file obfuscator, it does a very good job and includes strings and comments ;)
-
I don't know if this is related, but I have also found an example where the references is funny. In the simple example, try 'Find References' on the function called 'ReferencesOdd' and on the single use of this function in the function 'Func1'. In the first case I get three results: the function, the prototype and the use. In the second case, I only get the use. The other odd thing is, when I Preview the function, I get the function and prototype when I click on the definition; when I click on the use I get the function and two prototypes, one with '()' and one with '(void)' as the parameter list.
-
REVISED
@joecar: I was able to reproduce this only by adding the file to a project,
and turning on Document > C/C++ Options... > C/C++ Parsing Options,
"Tag function prototypes with no return type" = ON
Is this an option you need to have enabled?
@vandermyer: I can also reproduce your case, likewise, only if I turn on
Document > ANSI-C Options... > C/C++ Parsing Options > Tag function prototypes with no return type
I am putting together a hot fix to help references work better knowing that there are false-positives,
locally tagged prototypes with no return type.
I will also make some improvements to the parser for how we handle that archaic option for 25.0.2.
-
REVISED
@joecar: I was able to reproduce this only by adding the file to a project,
and turning on Document > C/C++ Options... > C/C++ Parsing Options,
"Tag function prototypes with no return type" = ON
Is this an option you need to have enabled?
. . .
I already have that enabled.
-
I think I have a simple example that shows the problem, see attached zip file containing files main.c and test.c.
main.c makes calls to functions defined in test.c.
Some of the calls in main.c are missing the parameter; doing Goto References from any of call where some instance of that call (that one or another) is missing the parameter produces only local instances.
Doing Goto References from test.c produces all instances (even the ones with missing parameter).
Try doing all 6 Goto References from main.c and compare with doing all 6 Goto References from test.c
LoL, I hope I got it right ;D
-
See updated attached zip (main.c, test.c), lol this one compiles and runs (using Visual Studio 2019).
-
Document > C/C++ Options... > C/C++ Parsing Options > Tag function prototypes with no return type
I already have that enabled.
The problem was that feature was enabled. Do you really want that?
-
Document > C/C++ Options... > C/C++ Parsing Options > Tag function prototypes with no return type
I already have that enabled.
The problem was that feature was enabled. Do you really want that?
I'll try that, thanks.
-
Document > C/C++ Options... > C/C++ Parsing Options > Tag function prototypes with no return type
I already have that enabled.
The problem was that feature was enabled. Do you really want that?
I disabled that and references are now working correctly, thanks, appreciate your help :)
Is there a way to save to file the current options/configuration (i.e. might want different C/C++ config for different projects)...?
-
Thanks for the fast response. Turning off option you mention seems to resolve the issue.