#import of .tlb files fail due to /Fo argument to cl.exe not being considered.

[akbyrd]

Environment

• OS and Version: Win 10 22H2
• VS Code Version: 1.76.2
• C/C++ Extension Version: 1.14.4

Bug Summary and Steps to Reproduce

Bug Summary:
#import statements are not resolved in C++/CLI code. This leads to error squiggles being disabled for the entire translation unit if C_Cpp.errorSquiggles is set to enabledIfIncludesResolve which makes that setting unusable in C++/CLI codebases.

Notice the error squiggle, despite the tlb sitting right there.

But this compiles just fine

Expected behavior:
#imports should resolve

Configuration and Logs

{
	"C_Cpp.default.compilerPath": "cl.exe",
	"C_Cpp.default.compilerArgs": [ "/clr" ],
}

Other Extensions

No response

Additional context

No response

[Colengms]

Hi @akbyrd . I think #import was introduced to support COM and does not specifically require C++/CLI. (#using is C++/CLI specific and can be used to import managed assemblies).

When using #import, it's necessary for the compiler to generate support files, including a .tlh file. That .tlh file is required by IntelliSense. After adding the #import statement, you'll need to issue a build in order to cause those files to be generated. Once the .tlh file exists, you may also need to ensure the output location is included in your include paths.

Let me know if that resolves the issue for you. If not, could you specify exactly what error message remains associated with the squiggle?

[akbyrd]

Even with the extra files present it doesn't resolve. It works if the tlh is next to the cpp, but not if it's in another directory, even if it's added to the path. It's fine if the tlb is in a another directory.

Here's a repro:
Bug.zip

[Colengms]

Hi @akbyrd . When I compile with cl.exe without any additional arguments, I see that the .tlh file is generated in the same directory as the including file (not the location of the .tlb file. When I run a build, the file is found where cl.exe put it. So, given the command line args you've provided, IntelliSense appears to be looking in the correct location, and this appears to be by-design.

However, a /Fo argument to cl.exe should influence the expected location for those files (if it specifies only a path, and ends with a backslash or forward slash), which is something we do not appear to be handling correctly. That is something we can fix.

[akbyrd]

Indeed, that looks like the underlying issue

[sean-mcmanus]

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.15.2 .

[akbyrd]

I'm testing the new release (1.15.4) and still running into some issues.

Issue 1
Quotes don't seem to be handled correctly.
This works:
"C_Cpp.default.compilerArgs": [ "/Iinclude", "/Foobj/" ],
This does not:
"C_Cpp.default.compilerArgs": [ "/Iinclude", "/F\"oobj/\"" ],
Same effect in settings.json or c_cpp_properties.json

Issue 2
Symbols from the tlb aren't resolving.

#import "LCDHardwareMonitor.PluginLoader.CLR.Interface.tlb"
ILHMPluginLoader* foo;

ILHMPluginLoader is one of the symbols provided by the tlb. This resolves in Visual Studio but still shows a red error squiggle in VS Code. The import resolves, but the symbol does not.

Issue 3
Should "go to definition" work on the import filename?