What VS displays when I hover over or click on a variable name

[dboggs]

When I click on a variable name, the name is conveniently highlighted. I like this very much and have come to depend on it. But it doesn't always do this. It seems stop suddenly and randomly; for example when I change from one source file to another, or after a debug run. Sometimes it works on some tokens but not others; other times it works on all of them even in the same file. Sometimes I can close VS, fire it up again, and it will be working. But not always. I have come up with many hypotheses why it sometimes does not work--the token is not strong typed; it is declared only in a module; I am in the debugging process, etc. But nothing seems consistent.

When I hover over a variable name, a popup window conveniently shows the variable type. This I also like very much but it doesn't always work.

Sometimes one of these features works but not the other; sometimes both will work; sometimes neither.

As far as I can see, there is no documentation about either of these features. It would be a lot easier to "reverse engineer" the seemingly random behavior if I knew how/when they are SUPPOSED to work.

I assume everyone else must experience this, no? Can anyone help me understand what's going on?

[mecej4]

DBoggs wrote:
I assume everyone else must experience this, no? Can anyone help me understand what's going on?

Definitely not, in my own case, and I have no recollection of anyone else reporting such a problem.

I use the VS debugger infrequently, and then only if other methods of debugging prove insufficient. At times, there may be questions about passing the arguments correctly to a library routine or a routine written in a different language than Fortran, or there may be a suspicion that the compiler has a bug. In these cases, it is often necessary to work in the disassembly window, but the source windows are useful to narrow down the selection of the breakpoint locations.

I have not noticed the behavior that you described. I also suspect that it will be next to impossible to see that behavior unless you provide source code and specific instructions to reproduce the suspected problem.

[dboggs]

I cannot provide specific instructions to reproduce the suspected problem. I was hoping someone could tell me. I find it unreproducible.

[mecej4]

You could help with reproducing the problem by being more specific and listing the circumstances where you made your observations. For example, you wrote, "When I click on a variable name, the name is conveniently highlighted." In which window do you see this -- source code, local variables, watch list, ...? Is the highlighting in the same window as the one in which you clicked? Does the source window display the subprogram within which a breakpoint has been hit? Is the program being executed, waiting for keyboard input, etc.?

I think that the debugger errs on the side of showing you whatever you ask for, even if you ask for a variable value when that value is not yet defined. You can hover the mouse over the source code of a subroutine that has not yet been entered, and you will see garbage values displayed for variables that you hover the mouse over. Therefore, being aware of context is important, and one has to train oneself to avoid attaching any significance to the displayed values of uninitialized and out-of-scope variables.

If you recompile with /Zi /Qtrapuv, you will see #CCCCCCCC in hex (after sign extension to 64 bits and conversion to decimal, -858993460) for integer variables that have not yet been assigned values. 

[dboggs]

OK, several things (I thought these were obvious to users of the VS editor but I guess not)

The problem occurs when editing source files in the source window. The highlighting I referred to is a featured called "highlight matching tokens" (or something like that).

Dsplaying the type of variable is the other feature that seems inconsistent; I don't know what that is called. For example, when editing a source file with a variable named lastrow a little display window will pop up showing INTEGER(4)::lastrow (because that's how it was declared. I also notice a variable named clegloc_new(igrph) and the popup will show CHARACTER(LEN=2) , DIMENSION(MAXCURVS)::clegloc_new (again because that's how it was declared).

And if I click on these variables they will be highlighted, along with all other occurrences of the name in the file I am editing.

These features "normally" (I should think) work all the time--when editing and when debugging. But occasionally they do not and I can't figure out why.

It has nothing to do with the display of variable values when debugging.

[Steven_L_Intel1]

I have found that the editor parser sometimes gets confused by certain Fortran syntax in the code. Please provide us with a test case and we'll investigate as similar issues have been fixed in the past.

[dboggs]

Thanks Steve. As far as test cases go, almost all of my programs--at least the longer ones--act up occasionally, but I find that all of the specific events are unreproducible. I will try to conjure up a simple one in which I can describe things that sometimes go bad, but this will take a little doing.

But this would help me greatly: are you saying that these features should ALWAYS work? Are there any known conditions under which they would not work by design?

Example: In a very short program I have no IMPLICIT NONE. There are two occurrences of the token irun. I launch the VS editor and find that clicking on irun does not highlight it. Could it be because it was not declared? I add a declaration INTEGER::irun, and then clicking on irun will highlight all (now three) occurrences. But this is not reproducible. I suspect that the sudden highlighting was because I simply added another occurrence of the token irun, and it just "happened" to be in a declaration statement; i.e., the editor just happened to be in a state where the highlight would work when I edit or add the token anywhere.

This will be a difficult one to demo!

[Steven_L_Intel1]

I assume you are referring to the source editor feature that will tell you how a variable is declared and not the debugger feature that tells you the variable's value. The former tries to parse the Fortran source file in the editor, not involving the compiler, and sometimes gets things wrong, though I would expect it to be consistent one way or another. If you have a source file that often has problems we'd like to see it.

If in fact you are referring to the debugger value tooltip, that's another thing entirely.

[dboggs]

It is not the debugger tooltip. It is strictly the editor features.

"a source file that often has problems"?...All of them! At least if they are very large (a thousand lines or so). I'll keep trying to realize a short one that has trouble.

[dboggs]

So I've been investigating this further trying to isolate some conditions under which the problems occur. So far I have the following, relating to the feature "highlight matching tokens":

1. Fire up VS and load any project containing AT LEAST two files. Click any source file in the solution explorer to show it in the edit window. Click on any variable name and observe that all matching names throughout the file are highlighted.

2. Set a breakpoint somewhere, anywhere, and begin debugging until execution stops at the break point.

3. While watching the file containing the breakpoint, observe that matching tokens continue to be highlighted when clicked. But switch to any of the other source files in the edit window, and the feature does not work.

4. Stop debugging. Observe that the observations in (3) persist; i.e. the feature continues to work in the last "active" file (the one with the debug breakpoint) but fails to work in any other file.

5. Close VS and restart. Behavior returns to normal.

To summarize: Failure of "highlight matching tokens" manifests subsequent to a debug run on a project containing multiple source files.

So far I have tested this on several different files and on two different computers, both of them running VS 10.0.40219.sp1 and VF 2013_sp1.3.202. The behavior described above is nearly identical (on one of them, at step 3, the failure occurs in most of the other files but not every one of them).

I have also tested on a third computer VF 2011_.11.344, and the above observations do not occur. Problems do frequently occur on that computer but I have not been able to isolate them. I will keep working on that.

[andrew_4619]

I stopped at point 1  in #10 is that is not something I have ever seen in any VS version I have used.

On digging, I found:

tools > options > text editor > fortran > Advanced > Highlight Matching Tokens

Is set false, (I presume a default setting) if I set true I get what you see at point number 1.

I guess this is the feature that is causing a problem. 

I usually click a variable and hit control F to highlight matches.

[dboggs]

Yes, that is the feature. I guess I should have mentioned that. I've been using it so long, and find it so useful, that I just assumed most people were using it. Shame on Intel for the "default-off" setting!

The problem with the ctrl-F technique is that it takes several keystrokes--and an extra one for each occurrence that you want to find; and when they are found it is after a zap-bang-there-it-is and you may have gone through a wormhole to a far place in the code and then you wait for your wits to settle down. With the highlight matching tokens feature the highlighting is automatic, and all occurrences are instantly highlighted (at least when the feature is working!), and then you can scroll in a controlled manner to get a picture of where the matches are. Warning: it is addictive! It is sorely missed when it is not working.

In addition, the instant feedback provided is very useful when typing new code due to the reassurance that you have typed variables correctly--no eye instead of an el or a one, a zero instead of an oh, etc. Why wait until compile time to find that a token is undefined (assuming you use IMPLICIT NONE)?

So--now that you and other readers know the nature of the culprit, how about some testing/reporting on how reliable it is?

[dboggs]

Does nobody have any further comments on this issue? I would at least like to know of anyone else experiences this difficulty, or if anyone even uses the token matching feature that I find so useful. Then maybe (or maybe not) I can impress upon Intel to give it some attention.