As far as I know, the vscode-cpptools doesn't provide intellisense inside macro definitions.
This is actually fairly reasonable. What a macro definition really means when the macro gets used is often highly dependent on context where it is used. After all... isn't one of the main features of macros?
Take for an (unrealistic, toy) example: #define FOO std::
. Let's say I expect to see identifiers for things declared inside the global std
namespace when I trigger VS Code to provide suggestions there. Who's to say some lunatic won't redefine what std
is and then use FOO
?
Granted, if it were instead #define FOO ::std::
, our imaginary lunatic is out of luck, but I'd wager this is a case of "It's too much work to distinguish between what is guaranteeable as known inside a macro body, so let's just not provide intellisense there."
Here's more (and probably better) food for thought: How would intellisense know what is declared inside the std
namespace at the point of the macro usage? That would depend on what standard headers have been included and what forward declarations have been made before the point of the macro usage. At one usage site, I might have included <string>
, and at another, not have included it. Etc. A macro can be used in multiple places. How do you give intellisense for something that can have different valid suggestions depending on where it is used?
Even with such a small example (and there are many varying others), there are already two challenges that make this unduly difficult for the vscode-cpptools extension to provide good suggestions/autocomplete for.
Granted- the vscode-cpptools extension can and will show problem highlighting at/inside the macro if any usage of that macro has problems, because it uses compiler diagnostic messages to find the "site" of the problem, and most compilers will report the specific macro line and column where the problem is happening in their diagnostic messages (in addition to the line and column of where the macro is being used).