SlickEdit Community

Archived Read Only Forums => SlickEdit 2018 v23 Beta Discussion => Topic started by: rowbearto on September 05, 2018, 02:20:10 am

Title: go to definition doesn't work when a .mk file is in a C++ project
Post by: rowbearto on September 05, 2018, 02:20:10 am
Look for components.tar.gz on support.

Follow the instructions in the README file to reproduce. It happens systematically with a clean config.

Additional info found after uploading the README:
1) In the README, notes point a) says "anonymous workspace", it should say "anonymous namespace"
2) If you do "find references" on "components" in the project containing the mk file, it finds references in the .mk file even though Tools->Options->Editing->Context Tagging->Allow mixed language references is set to "off".
3) If you open the nomk.vpw workspace and do find references on "components", a mysterious dialog appears that says: "No more references, pop from stack?" appears. Can you explain what this means? No matter what I choose (yes or no), the references window will show 2 unexpandable files.
Title: Re: go to definition doesn't work when a .mk file is in a C++ project
Post by: Dennis on October 10, 2018, 11:00:46 pm
3) The "No references pop from stack" message should be fixed in beta 6.  You can still have situations where you have not references.

2) Because the "components" label is the one selected by tagging, it is included in the references search regardless of the mixed languages setting.  The file containing the symbol's definition is always included in the references search.

1) This is a hard problem.  Putting all those declarations in an anonymous namespace makes them static to the module that they are declared in.  This is why push-tag selects the declaration in the makefile, because there's a symbol named "components" in the global space which is not hidden away.  Now, if you do not have the makefile in your workspace, it doesn't have that symbol to grab, so then push-tag reverts to desperation mode and just finds any symbol named "components", ignoring the fact that it is static to another module.

0) Removing the makefile from the picture is a good workaround.