You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Computed include go to definition (ctrl+click) #13100
If using SSH remote, specify OS of remote machine:
Bug Summary and Steps to Reproduce
Bug Summary:
I am not sure if this is a bug or intended, but would be a shame if this is intended.
I am investigating using "computed includes" within our project and vscode ctrl+click does not seem to be working on them. The extension properly resolves the defines and the test source file compiles successfully. However, if I try to go directly to an included header file, directly by using ctrl + click, it is inoperable.
Side note. Ctrl + click seems to also not be working on an absolute path.
The power of computed includes comes from being able to use #defines within includes. We want a slight variation that uses directories instead, but the whole slew does not seem to be working.
Steps to reproduce:
Define test.c with a computed include using a macro (which expands a directory), a 'normal' computed include that uses a computed include directly from a define, an absolute path include, and something that works such as #include <stdint.h>.
Define c_cpp_properties and add the relevant defies to be used in expansion.
Try to ctrl + click or go to definition on all of the computed includes and or the include of an absolute path and watch as they do not seem to work but ctrl + click on stdint.h does.
Expected behavior:
The extension properly expands the macros to the correct paths. Ctrl + click should work on the expanded macro used within a define. Ctrl + click should also work on absolute paths.
Note in my examples I am on windows and very explicitly defining all of my paths with forward slash '/', not backslash so that I can be portable. Windows accepts either, but unix only accepts forward slash for path separators.
test.c
c_cpp_properties
macro expand STR(THE_DIR/test.h)
macro expand TEST_H
Ctrl click / go to definition does not work on lines 1, 3, 5
Ctrl click / go to definition works on line 7
Greyed out is my user name
Compiled test.c using clang, which works successfully
Go to definition not working on the absolute path is a bug. Works in VS.
Go to definition not working on the macro in the #include is a bug. Works in VS.
Go to definition on the include not going to resolved macro path doesn't work in VS, i.e. feature request...I'm not sure how the user would differentiate being whether the macro is the target or include file that it resolves to is the go to target.
How many people are going to be using macros like this on a daily basis? I will be because I have a very specific use case that this fits perfectly for. However, I would argue the intent is very clear that it should jump to the header file in this case and not try to jump to the macro definition. I care way more about jumping to the header than to looking at the macro definition. In fact, I just need to hover over the macro to see the definition of the macro in the popup as above.
I would say we should find a way in the ui or command that it is possible to jump to both; however, 99% of cases will want to jump to the header.
To be honest, looking at how ctrl + click behaves in the extension now is a little odd to me. When I press control and mouse over an include string, I can actually highlight each path segment as a target for the invocation. That's weird. It should just highlight the entire string.
Regardless, maybe this is a chance to think about and implement some different behavior that kills both of the above birds with one stone. Instead of a ctrl+click target being the string, what about it being the #include instead? I press control and mouse over the include, which then highlights / underlines the entire line. Clicking then jumps to the header file. Now your ambiguity is resolved. Stop making the string literal in the include the click target. Now when the user does a control + click on a macro or define in the include as above, the invocation jumps to the macro definition.
Activity
sean-mcmanus commentedon Jan 3, 2025
#includeis a bug. Works in VS.LostTime76 commentedon Jan 3, 2025
How many people are going to be using macros like this on a daily basis? I will be because I have a very specific use case that this fits perfectly for. However, I would argue the intent is very clear that it should jump to the header file in this case and not try to jump to the macro definition. I care way more about jumping to the header than to looking at the macro definition. In fact, I just need to hover over the macro to see the definition of the macro in the popup as above.
I would say we should find a way in the ui or command that it is possible to jump to both; however, 99% of cases will want to jump to the header.
To be honest, looking at how ctrl + click behaves in the extension now is a little odd to me. When I press control and mouse over an include string, I can actually highlight each path segment as a target for the invocation. That's weird. It should just highlight the entire string.
Regardless, maybe this is a chance to think about and implement some different behavior that kills both of the above birds with one stone. Instead of a ctrl+click target being the string, what about it being the #include instead? I press control and mouse over the include, which then highlights / underlines the entire line. Clicking then jumps to the header file. Now your ambiguity is resolved. Stop making the string literal in the include the click target. Now when the user does a control + click on a macro or define in the include as above, the invocation jumps to the macro definition.
Just some thoughts
sean-mcmanus commentedon Jan 3, 2025
LostTime76 I've filed a feature request on VS at https://developercommunity.visualstudio.com/t/Enable-C-IntelliSense-Go-to-definition/10822893 . We consider that a "feature request" and not a bug because the code to handle it that way never existed.
sean-mcmanus commentedon Jan 3, 2025
LostTime76 I've moved the absolute file case bug to #13103 .