| T O P I C R E V I E W |
| hajokirchhoff |
Posted - Oct 18 2021 : 05:19:04 AM
I've been having this problem for several years, but never bothered to write until now:
I have a symbol "m_destinations", which appears four times in my sourcefile.
"Find Previous by Context" finds all occurrences, but "Find Next by Context" only finds the last two.
Say the symbol is on lines 80, 103, 340 and 341.
"Find Next by Context" will jump from 340 to 341 and back to 340 and so on.
"Find Previous by Context" will find all four.
Any ideas?
Best regards
Hajo |
| 12 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Aug 18 2022 : 07:45:11 AM
It turns out the problem is the logical AND's, && being used to compose a log message. Not something I would have expected to be a problem, so thank you for the code sample, that would have been a lot harder to work out without the sample:
case=148454 |
| feline |
Posted - Aug 17 2022 : 11:37:09 AM
I have the file, and I am seeing the same problem here, many thanks for this. Now to work out what is going wrong... |
| feline |
Posted - Aug 17 2022 : 11:30:54 AM
By the sounds of it, just the single code file would be ample, assuming you can get permission to share it without too many problems.
Triggering a VA symbol database rebuild, via:
VA Options -> Performance -> Rebuild symbol databases
should not make any difference, but it would be an interesting test to see if this fixes the problem. If it does then we know that it's not quite as simple as something in the file confusing our parser, but does suggest a macro might be a problem.
Assuming the problem still shows up after a symbol database rebuild, does VA Outline look correct for this file? It's not uncommon for code structures that confuse our parser to also show up in VA Outline, which can give you a good clue as to where the problem starts in the file. |
| hajokirchhoff |
Posted - Aug 17 2022 : 08:21:19 AM
The good news is that the error is reproducible even with just the single file and even stripped down to just the function. I see this even on a different machine. However I did not clear the VisualAssist Cache and History, so that might still be the cause.
What other files should I save/zip so that you can debug this?
I have created a solution with just this file - perhaps the solution is not even neccessary, since I haven't even added the file to the solution. Just dropped it into the same folder.
I need to get permission to send you the file, but I think this should be possible.
Regards
Hajo |
| feline |
Posted - Aug 17 2022 : 07:13:54 AM
Thank you for the screen shots, they show the problem very clearly. I have seen this sort of thing before, but normally only with something that is clearly confusing our parser, for example:
class DuplicateNameOnParameter
{
private:
short nDuplicatedName;
DuplicateNameOnParameter(short nDuplicatedName) : nDuplicatedName(nDuplicatedName) { }
};
which shows the problem in reverse, since VA thinks all instances of "nDuplicatedName" are the same symbol. Perfectly legal, if confusing C++.
If you have a few minutes, can you please try making a new, default C++ solution, and copy the single code file the screen shots are from across into the solution, and then open the solution and file. Do you still see this highlighting problem? This will tell us if the trigger is inside this file or somewhere else.
I am guessing that something is confusing our parser further up the file, but that's just a guess. A couple of possibilities are strange #define's or unmatched brackets, like:
void thisCompiles()
{
#if 0
{
{
{
#endif
}
Assuming the problem can be reproduced with just the single file, would it be possible to get a copy of just this file, purely for testing purposes? I realise this is often not possible, but it's worth asking on the off chance. The file would only be used to edit it down to find a minimum case, to understand the bug.
If this is an option please send me the files via email:
[email protected]
including this thread ID or URL in the description, so we can match it up. |
| hajokirchhoff |
Posted - Aug 17 2022 : 06:22:02 AM
I am having the problem again and this is a very clear case of weirdness...
Here the cursor is positioned on line 956, on the second "dropped_frame_count" reference and all other read/write references are highlighted
*** EXCEPT the ones inside the if statement on line 962
https://1drv.ms/u/s!AsT4yr2-6YnxmwX5VuMz5dFNPMDA?e=KkQjwt
And now the cursor is positioned on the first "dropped_frame_count" reference on line 963, _inside_ the if statement.
https://1drv.ms/u/s!AsT4yr2-6YnxmwZGa6OK6yGRtOLR?e=PzYcaU
Suddenly only the two references inside the if statement are highlighted, which weren't highlighted before.
Find next/previous shows the same problem.
The thing is: This is a local variable with a very limited lifetime. Also the "if" statement on line 962 isn't really that complicated. The `m_work_item2_is_dropping_frames` variable is a bool member variable. |
| feline |
Posted - Oct 19 2021 : 05:54:24 AM
To be honest I normally just use the Find References Results list myself, so won't have noticed this very easily. Still, if Find References its self is working correctly then I would expect next and previous to work correctly, and to work the same.
Question mark entries in the Find References Results list can be disabled, so if you have turned off showing them then they will never show up, even if they are being picked up. Still, if the results generally look correct for Find References then this suggests this isn't the problem.
If this was a "normal" problem with macros then I would expect it to effect next, previous and the Find References Results list its self equally. Really strange, I am not sure what to make of this, but if we can get a case to study I am going to do everything I can to get to the bottom of this oddness. |
| hajokirchhoff |
Posted - Oct 18 2021 : 11:03:46 AM
Will do. I've had this happen all the time. Find references will find all of them and they look fine, although I have not checked to see if they where unknown/guesses. Come to think of it I am pretty/very sure that I have not seen a questionmark.
I've always assumed that VA has a hard time parsing the boost library with it's many macros and I sort of accepted it as "thats life".
I will keep you updated next time I encounter this behaviour. Find Next != Find Previous is something that happens so often to me, I usually cycle through references backwards. :) |
| feline |
Posted - Oct 18 2021 : 10:47:18 AM
Have you seen this problem in different places over time? Or has it mostly been in this code that you have encountered it?
The fact that changing the code, and then changing it back has "fixed" the problem suggests that something is confusing our parser.
When you encounter a situation like this can you please try running Find References, and then right click in the Find References Results window and make sure that:
Display unknown/guess hits (G)
is turned On, assuming it is offered? If there are entries that VA is not sure about, which are shown in the Find References Results list with a question mark icon, then that might be a clue to this problem. At the very least it will tell us that VA isn't totally sure about how to parse your code, which is something we could look at to try and fix. |
| hajokirchhoff |
Posted - Oct 18 2021 : 08:31:57 AM
Reverted the change, but now Find Next works as expected. |
| hajokirchhoff |
Posted - Oct 18 2021 : 08:15:28 AM
It's a member variable. The problem here appears inside a template member function. The structure is like this:
struct recording_stream {
string m_destinations;
template <typename Archive>
void serialize(Archive &ar, const unsigned int version)
{
ar & boost::serialization:make_nvp("destinations", m_destinations);
...
if (Archive::is_loading()) { // possible hint what might be going wrong here??
if (m_destinations.empty())
m_destinations = settings.m_recording_folder;
...
}
Find Next did find the last two instances, the ones inside the if (Archive::is_loading())
`is_loading` is a member of the template class `Archive` and is probably a constexpr (or should be). It get`s resolved at compile time.
But I still don't understand why Find Next should work any different than Find Previous.
BTW, I've modified the two lines in question an hour ago. All of a sudden Find Next works as expected.
I'll revert my change and let you know what happens.
|
| feline |
Posted - Oct 18 2021 : 06:24:23 AM
Is this a class member variable or a local variable? The "m_" at the start of the name suggests a class member, in which finding all references across all member functions would be sensible. If instead it is a local variable name, declared separately each time in different functions then the different functions should not be found.
Either way that is really strange, so I am curious as to what is going on and wrong here. |
|
|
