Can't navigate to definition in .cc file from .hh file in beta2

[rowbearto]

Look for gotodef22.tar.gz on support.

Instructions to reproduce are in the README file inside of it.

Need to follow the exact steps in there to reproduce, as it was tricky to find out how to get it to repro with a simple project.

This issue occurs with beta2 on Linux x64 CentOS 7.2

[rowbearto]

I still see this problem in beta3

[Clark]

Not able to reproduce this so far. I tried beta 3 and beta2.

How easy is it for you to reproduce this with your steps?

Do you need all the files to reproduce this problem?

I tried adding a bunch of real source files as replacements to the missing files but it didn't help.

[rowbearto]

I don’t need all the other files, but I did need the full project that refers to it to reproduce.

I was able to repro following the exact steps in the readme. I did it at least 2 times.

Start with default config, don’t load workspace, close SE, copy user CFG, reload SE, load ws, close SE, delete vtg and vpwhist, reload SE, load ws, then repro. It is important to follow these steps exactly, especially the deletion of vtg and vpwhist. Took me some time to figure out these repro steps. Also Linux x64.

[rowbearto]

When starting with default config, use -sc option with nonexistent directory, that is what I did

[Clark]

Two of us have tried to reproduce this with your steps with no luck. Not sure why we can't reproduce this. One time I thought I got it to happen but I forgot to open the workspace.

[rowbearto]

I was able to reproduce it again just now using my exact steps. And I made sure I loaded the workspace. After reproducing, one more time I closed SE, deleted vtg and vpwhistu, reopened SE and workspace, and saw it again. If I close SE and reopen without deleting the vtg and vpwhistu, it doesn't happen.

There is one more thing you can try. I always launch SE with options: "-st 0 +new", in each step of the README I did this. It happens from a script, so I forgot about it. Try using "-st 0 +new" each time you launch SE. I will now try to see if it doesn't reproduce if I omit "-st 0 +new".

[rowbearto]

It still reproduces for me even if I omit "-st 0 +new".

The only other thing that I can think of is the very first time I do goto definition in the sequence, SE is tagging a bunch of my system header files. I wonder if this is the difference between my situation and yours, something in the tagging of my system header files is different and causes this conflict?

If you still have that CentOS 7 virtual machine that I provided to you few months back for a different issue, maybe you can try it there?

[rowbearto]

I have reproduced this about 3 or 4 times now on beta3, linux x64, centos 7.2

[rowbearto]

Found another hint. It seems to happen while background tagging is occurring. So if I don't initially delete the vtg/vpwhistu and it is working, then I go to the "Project->Retag workspace", then uncheck "Retag modified files only", check "Generate references" and check "Retag files in background when possible", and click OK. Then when I try to goto definition from the header file at that time, I have the issue. The background tagging takes a while even though all the other files are not there (those files are at different paths on my machine, so they are not there in my sample either). It takes some time to tag non-existent files, and while this is going on I have the issue. This could also be why deleting the vtg had something to do with it.

[rowbearto]

In my real project where I first noticed this error, I did not tell it to retag the workspace. You could make that case that when I deleted vtg that the reason it does not go to definition is that it hasn't fully tagged yet. But in my real project, I did not ask it to retag the workspace. Also when telling to retag from project menu and leaving unchecked "modified files only", I would think that SE would retain the old tagging info while it is retagging?

Perhaps the reason you didn't repro it is that you were not fast enough? But now with the new step of using the menu to retag the workspace and doing it quickly, maybe you can repro now?

[Clark]

I've been thinking the same thing as you. That's why I added 20,000 real files to your project in an attempt to not allow it to finish tagging before I hit Ctrl+Dot. I'm actually surprised it doesn't happen for me because the tagging doesn't appear to be finished when it's working. I would expect it to have to be finished in order to work.

I'll try this some more.

I do have a fairly fast machine with only SSDs.

[rowbearto]

In my project all the files are on networked nfs mounts

[Clark]

I finally got this to happen after I added about 84000 real files to the project. After go to tag kept going to the same line for a while, I waited until tagging of the workspace got completed. Once tagging of the workspace got completed, then go to tag works for me.

I'm not seeing any bugs here. If I try to exit SlickEdit before tagging of the workspace is done, I get a message box which allows me to cancel tagging the rest of the workspace. If I select cancel, the next time I open the workspace SlickEdit will keep trying to tag the rest of the files in the workspace. If it's not finished, go to tag doesn't always work. Once it's finished, then it works.

[rowbearto]

When I first saw this symptom in my real project, I did not tell it to retag. Also with the test project, once it is fully tagged and I go to project menu to retag workspace and unchecked modified files, it happens. I would think this is a bug, while retagging, shouldn’t it keep old tags until they are replaced?