Go To Definition on a managed function should not attempt to open a DLL as a text file

[HOMODELUNA]

Type: Feature Request

Once I want to code a tool for .net I found that I have few supports.Intellisence doesn't recognise the code concerning CLR.

//a.cpp
#using<system.dll>
using namespace System;
int main(void){
    Console::WriteLine("Hello World");
    return 0;
}

This code surely passes the compilation with cl a.cpp /clr ,but I got these Intellisence errors:

name followed by '::' must be a class or namespace name
"#using" requires C++/CLI mode

I think it it because intellisence can't find a file declaring these namespaces and function.So I build a header.

//tips.h
namespace System{
class Console final{
public:
    static void WriteLine(...);
    static void Write(...);
private:
};
}//namespace System

However, this will trigger a redefination error at compile time.

system.h(4): error C2011: redefination of “System::Console”:“class”

Is there a way to get tips and Intellisence check without coming into compile time errors? Can this problem be solved by extra features? or by manually making headers?,or other snippet options? I wish there is a method.

[Colengms]

Hi @HOMODELUNA . The C/C++ extension should support IntelliSense for C++/CLI. Could you elaborate on how you have configured the extension?

I suspect the issue may be that the location of the assembly you are referencing needs to be provided via an include path. For example, in c_cpp_properties.json :

"includePath": [
    "${workspaceFolder}/**",
    "C:/Program Files (x86)/Reference Assemblies/Microsoft/Framework/.NETFramework/v4.8"
],

[sean-mcmanus]

We should handle the various C++/CLI command line arguments for configuration when set in the compilerArgs property.

[HOMODELUNA]

@Colengms
I added the args as "compilerArgs": ["/clr"] toc_cpp_properties.json ,and got some tips.
Including "C:/Program Files (x86)/Reference Assemblies/Microsoft/Framework/.NETFramework/v4.8" seems to be uneccessary.

As you can see, red wavelines have disappeared, and the tipblock successfully showed up. However when I tried to follow the function with F12,it redirected me to the dll containing the function.

it seems that the editor can't directly see into the dll. Is this the best it can do, or detailed declaration and docs can be shown by some othed ways?

I remenber there was an object explorer in Visual Studio to show hepdocs in the dll, and using it may simplify the staff.

Does VS code has a similar one, or can I build an extention to call that observer?

[Colengms]

Hi @HOMODELUNA . The C/C++ extension does not currently have that feature. Would the following feature request address what you are looking for?: https://github.com/microsoft/vscode-cpptools/issues/3799 If not, you could open a feature request, or we could convert this issue into a feature request.

[HOMODELUNA]

@Colengms

Maybe the expected feature is to look into the dll,and display the docs in it. I'll be grateful if you are willing to add this feature.

Feature Request : C++/CLI Intellisence

• avtivated when using compiler action/clr or other options
• new keywords coloring : gcnew(not yet)
• new grammar pattern : handle :T\^ (ok)
• be able to show help text when mouse hangs on the function/variable (not complete)
• follow into the declaration of in-dll funcions with F12(not yet)

[Colengms]

Hi @HOMODELUNA . Colorization for the gcnew would be best done syntactically/lexically, as it's a keyword. That type of colorization is done by VS Code itself, based on the TextMate grammar contributed from this repo: https://github.com/jeff-hykin/better-cpp-syntax You might consider posting a request to colorize gcnew in that repo.

Could you give me an example of T\^? If you are referring to use of a ^ to indicate a managed reference, that should already be supported by the C/C++ extension. Are you seeing a case in which it is not?

I assume you are referring to showing help text for functions defined in managed DLL's. The help text we show on hover comes from comments in code. I don't believe there will be any documentation retrievable from a managed DLL.

I don't believe the Go To Definition feature should be attempting to open DLL files as text files. I can use this issue to track that as a bug.

[HOMODELUNA]

Hi @Colengms

• gcnew
  I'll then report this to https://github.com/jeff-hykin/better-cpp-syntax,thank you for the direction;

• T\^

Sorry, it's a typo ,I just wanted to mean T^ as handler. It's usually recognized except one occasion: as you can see,when used as a type, it isn't colored as the following pointer. Maybe it's still the staff of better-cpp-syntax.If so ,I'll report it there together with the former.

The help text we show on hover comes from comments in code. I don't believe there will be any documentation retrievable from a managed DLL.

I agree with you. As DLL doesn't contain any documentation, it shoudn't be redirected to withGo To Definition, so going to the dll and trying to open it as text should be regarded as a bug.
If I still want to show text on hover or on Go To Defination, maybe I should build a metadata file as C# uses and refer to this. Writing comments in the metadata would be a solution.

a replica of C# [metadata]file

[Colengms]

Hi @HOMODELUNA .

Regarding the ^; Are you referring specifically to colorization? In the case of int*, the colorization appears to be coming from the TextMate grammar. You can determine this using the Developer: Inspect Editor Tokens and Scopes command and clicking on a token to inspect. Any token in a C/C++ file that indicates a semantic token type has been identified by the C/C++ extension. Any that do not specify this, have been colorized based on VS Code's TextMate grammar for C/C++. Since int^ can be determined syntactically/lexically, it's not something that would normally be handled by the C/C++ extension's semantic parser. You might consider opening an issue in the TextMate repo I referred to earlier. However, because ^ is also a bitwise operator, and TextMate grammar is based on regular-expressions, it might be challenging to supporting.

I'll go ahead and convert this bug to tracking the opening of DLL's as text files. If there are any issues here that we haven't addressed yet, we could open additional issues.