Changes to header files are not reflected in dependent translation units

[killerkalamari]

Quite often, I'll manually refactor a header file or source file, and there will be a bunch of "Problem"s listed at the bottom, but then I'll compile and the compile will be successful. Well, the compile could be too permissive, right? However, I've discovered that, whether I compile or not, if I close the folder (or workspace), and then reload it, then the extension will notice that everything's actually fine (the errors are no longer there after the load). Conversely, I might make a change that results in a compile error, and it doesn't catch it, until I reload. I speculate that it is simply not noticing all the changes I'm making and so it misses chances to update the Problems list. I tend to run with a couple windows open (one for each monitor), so I don't know if that is involved.

I'm confident that eventually these problems will be fixed, but in the meantime I'm wondering how hard it would be to add in a command (with hotkey) that I can press periodically to have it refresh the Problems list without having to close and reload all the time. Thanks!

VS Code 1.19.3
C/C++ extension 0.14.6
Ubuntu (64-bit)

[bobbrow]

There is definitely something wrong with the refactor scenario if you are seeing out of date problems. One scenario I know we don't do correctly yet is when a header is updated we don't update all translation units that might be referencing it. We only update the first one that was opened.

For instance, if A.cpp includes A.h and B.cpp also includes A.h, IntelliSense for A.h is currently only linked to A.cpp or B.cpp, not both. We should fix this sooner rather than later. I'll mark it for March.

In the meantime, VSCode's "Reload Window" command will reset all of the translation units without having to completely close the actual VSCode window.

[killerkalamari]

I think you're right. I have a master header that #includes a bunch of file-specific headers. Then, I have multiple c files #including that master header:

File specific headers: B.h, C.h, ...
Master header: A.h, which includes all the file specific headers: B.h, C.h, ...
Source files: B.c, C.c, ... each of which includes A.h

The misses occur when I'm modifying those file-specific headers, or also when modifying the c file in a way that makes it incompatible with the header.

Thanks for the "Reload Window" mention, it works! From what I just read, I think VS Code allows assigning hotkeys to any command, so I should be good to go once I learn to do that.

Edit, figured out the hotkey! Here's how I did it:

1. Press Ctrl+K Ctrl+S to bring up the Keyboard Shortcuts window
2. Search for "Reload Window"
3. Right-click "Reload Window" in the search results and choose "Add Keybinding"
4. I chose Ctrl+Shift+R for the binding, so that's what I pressed, then pushed Enter. This conflicted with another key combo ("Show Conflicts" told me of the conflict). Here's how to resolve the conflict:
5. Up at the top next to "For advanced customizations..." click keybindings.json.
6. Add a comma after the "command" line, and add a new line: "when": "editorTextFocus"
7. Save the keybindings.json file. Press Ctrl+Shift+R when editing to refresh the Problems list.

[sean-mcmanus]

This was fixed for 0.16.1. Let us know if there's a still an issue.

[killerkalamari]

Thanks for your work on this!

Unfortunately, it still seems to be a problem, but only with multiple windows (File -> New Window). If I run everything in the same Visual Studio Code window, it seems to work. However, if I run with 2 VS Code windows then changes in the header aren't recognized by the c file in the other window (I put headers on one monitor and c files on the other).

In my original post, I raised a suspicion that my use of multiple VS code windows was to blame for my problems. Is it possible that maybe there's something to that after all?

Verified that I had the latest code and the 0.16.1 C/C++ plugin.

[sean-mcmanus]

I'm not able to repro a bug with 2 VS Code instances -- I see a lag of 5 seconds before the re-squiggle occurs though. We might be able to reduce that lag. Is that what you're seeing? I'm seeing hover results immediately get reflected with the correct results. I have a simple scenario with a single .h/.cpp file, modifying the header. Let me know if the repro requires something more complicated.

[sean-mcmanus]

Oh, I'm seeing a bug with error squiggles not updating until a file is edited (or closed/opened) when the header is modified. Repros with just 1 VS Code instance. I filed bug #1779 to track this issue. The intelliSense engine appears to be updated (i.e. hover works), but the error squiggle request isn't being resent for the file.

[killerkalamari]

Here's a recreate. Note: I created and saved the files from within VS Code:

test1501.h (open in window 2), create/save this file first:

typedef struct {
    int c;
} a;

test1501.c (open in window 1, the original window), create/save this file second:

#include <stdlib.h>
#include "test1501.h"

int main() {
    a *b = malloc(sizeof(a));
    b->c = 1501;
    return 0;
}

In the above, b->c has a squiggle under the c, and the tooltip says struct "<unnamed>" has no field "c". This squiggle is visible with a saved test1501.c file. After doing a "Reload Window" of the test1501.c window the squiggle goes away and it says "int <unnamed>::c", which appears correct to me.

As a second test, changing int c; to int c2; in the header and saving test1501.h (and waiting more than 5 seconds), b->c is still happy. If I then do another "Reload Window" of the test1501.c window, I then get the squiggle under c.

Hope this helps! Please let me know if there are any additional details I can provide.

[sean-mcmanus]

I'm able to repro the problem now. It occurs when the header is modified externally to the current workspace and the header isn't open in the instance that has the C++ file open. I wasn't able to repro it because I had the header file open in the VS instance that had the C++ file open.

I opened bug #1780 to track this.