go to declaration

[Bestie123]

Environment

• OS and Version: windows 10
• VS Code Version: 1.69.2
• C/C++ Extension Version: 1.11.4
• Other extensions you installed (and if the issue persists after disabling them):
• If using SSH remote, specify OS of remote machine:
• A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).

the display of all parameter declarations disappears

directory used as a project: https://github.com/llvm/llvm-project

Bug Summary and Steps to Reproduce

directory used as a project: https://github.com/llvm/llvm-project

the path to the file to open: G:\llvm-project-main\llvm-project-main\clang\include\clang\Basic\CodeGenOptions.h

at the beginning of the project opening, if you hover the cursor over "setDebugInfo", all definitions of this parameter are shown

if you right-click on "CODEGENOPT" and select "go to declaration", then all the places where this parameter is declared will be displayed in the list

next comes some kind of file processing and when you hover the cursor over "CODEGENOPT", the display of the remaining parameter declarations disappears

also, the "go to declaration" function stops working for the "CODEGENOPT" parameter. for the "ENUM_CODEGENOPT" parameter, the "go to declaration" function works, but other declarations of this parameter in this file stop being displayed.

the display of all ads disappears after the output of this debugging information to the console

Expected behavior

1. it is expected that all parameter declarations will be displayed when the mouse cursor hovers over it

2. it is expected that when you right-click on the parameter and select the "go to declaration" option, all the places where this parameter is defined will be displayed

3. the expected behavior when hovering the cursor can be viewed in the wboq documentation generator

https://blog.weghos.com/llvm/llvm/clang/include/clang/Frontend/CodeGenOptions.h.html#34

Code sample and Logs

c_cpp_properties.json


{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "windowsSdkVersion": "10.0.19041.0",
            "compilerPath": "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.32.31326/bin/Hostx64/x64/cl.exe",
            "cStandard": "c17",
            "cppStandard": "c++14",
            "intelliSenseMode": "windows-msvc-x64"
        }
    ],
    "version": 4
}

Screenshots

No response

Additional context

No response

[Bestie123]

an example of displaying navigation in visual studio. as you can see, all parameter definitions are displayed here. But navigation in visual studio is inconvenient due to the fact that the syntax is not displayed.def and in def there is no code navigation in the drop-down list, so it is preferable to use vs code + c/c++ extension

you may also notice that visual studio and vs code give references to the clang/Frontend/Code Gen.def and flang/Frontend/CodeGenOptions.def parameters instead of displaying only clang, as the woboq documentation generator does, this is probably due to various code analysis technologies, I read somewhere that woboq uses analysis, in which the source code is analyzed sequentially, as when compiling and building a project

[Colengms]

Hi @Bestie123 . Does this issue still occur for you with 1.11.5 or 1.12.1 ? We recently addressed a crash issue specifically with llvm-project, that could have led to this behavior.

[Bestie123]

Hi @Colengms . version 1.12.1. now the navigation is displayed correctly. it is not yet possible to generate code and compare it more thoroughly with the navigation display in woboq, but in general it seems that everything works correctly

[sean-mcmanus]

So we can close this issue?

[Bestie123]

@sean-mcmanus . yes, you can close

[Bestie123]

@sean-mcmanus I made a mistake, the problem still occurs, I didn't have time to report it, I can record a video with a demonstration of the problem, also, if necessary, I can provide an archive with the analyzed llvmproject code and an archive with the generated woboq documentation for the first archive. Should I open a new question or can I write here?

[sean-mcmanus]

You can add more info to this issue.

[Bestie123]

@sean-mcmanus

• my archive with llvm-project-14.0.6 without /build/bin /build/ /build/lib /build/tools folders, because these folders are about 100 gigabytes after the project compilation.

The file is zipped using the 7-zip archiver without a password, then encrypted using the encrypto program. Encryption password: 12345 https://vk.com/s/v1/doc/KnPBtXnXDhjByaKG-4Ss_xjJ2kqalJbqptA1KHtDesq8AvAGGss

You can also download the source code on github: https://github.com/llvm/llvm-project/releases/tag/llvmorg-14.0.6

• an archive of generated woboq documentation (optional) (useful for an example of how definitions should be). Warning!! The woboq documentation has 700,000+ generated files and weighs 6 gigabytes when unpacked. Due to the fact that the files are small - copying and deleting files can be very slow Private definitions not showing up in woboq: https://github.com/KDAB/codebrowser/issues/98

To use the documentation, you must place the unpacked folders on a web server (for example, on a local one). example of opening the root directory documentation: http://localhost/llvm3/index.html archive password: 12345 archive: https://vk.com/s/v1/doc/GZC_zXGMoT8q7AIR7BB3OCamyQMkdJ8W_9xx1_kllxlfCuO59Pw

• Video showing problems: https://www.youtube.com/watch?v=PTMfVhITUNM At 1:12 there is initialization and adding sensations

AT 1:20 Compared to the screenshot from Visual Studio, the definition of CodegenOptions.def is missing https://user-images.githubusercontent.com/15684883/183204158-0d60229c-6ff8-4948-a3b0-96bb1ac2118f.png

At 1:49 Exception initialization or access occurs and then at 1:53 there is a new list of definitions that contains one definition, and the old ones disappear somewhere

At 1:59 when calling the "go to declaration" call in development at 2:08 now it appears that no matches were found, but if you accidentally open the CodegenOptions.def file, then at 3:14 the call to "go to declaration" will display at 3 :28 list of all matches, but there will be no matches that were at 1:20

compileCommands and databaseFilename in c_cpp_properties.json can be omitted. If you use compileCommands, then you need to change the paths to the source files inside compile_commands.json to your location

Code example c_cpp_properties.json

{ "config": [ { "name": "Win32", "include path": [ "${workspaceFolder}/**" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "windowsSdkVersion": "10.0.20348.0", "compilerPath": "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/Llvm/x64/bin/clang++.exe", "cStandard": "c89", "cppStandard": "C++14", "intelliSenseMode": "windows-clang-x64", "view": { "databaseFilename": "G:/browse.vc.db" }, "compileCommands": "${workspaceFolder}/build/compile_commands.json", "Merge Configurations": true } ], "version": 4 }

[Bestie123]

@sean-mcmanus

I also noticed another problem. It is probably a separate error

1. Run vscode
2. Now open the file "llvm-project-llvmorg-14.0.6\clang\include\clang\Basic\CodeGenOptions.def".
3. After analysis, screenshot 1 shows that when hovering over the "CODEGENOPT" parameter, an error appears
4. If you try to open some .cpp file, then after parsing open CodeGenOptions.def, then the errors will stop appearing. This can be seen in screenshot 2.
5. Screenshot 3 shows that before opening the .cpp file, if you right click "CODEGENOPT" and select "Find All References" from the drop down list, then 1) Screenshot 3 shows that 173 links were found, and below are some vague links.

Screenshot 4 shows that after opening the .cpp file, if you right-click "CODEGENOPT" and select "Find all References" from the drop-down list, then 2) Now 180 found links are displayed

Visual Studio has a similar issue. The .def file is parsed normally, but then something happens and nothing helps to eliminate parsing errors. Repairing Visual Studio doesn't help, and neither does restarting the computer. In visual studio, this problem affects the search for links, links are no longer found due to errors in the analysis of .def files. Screenshot 5 shows an example of a similar problem in visual studio. Screenshot 6 shows that the file was previously analyzed without errors, but then something happened, and analysis errors already appear in screenshot 5. This problem is relevant for visual studio 2019 and 2022, it has not been tested in older versions. P.S. screenshot 6 was taken a few days earlier than the rest.

[sean-mcmanus]

FYI, if you're able to repro the bug in VS 2022, then it's preferably that you file a bug directly on the VS developer community site, since it's mostly caused by shared code...otherwise, we have to do that ourselves, and it might take us longer to get around to doing that.

[Bestie123]

@sean-mcmanus , I submitted a bug report to the Visual Studio developers as you suggested. Here is a link that might be helpful: https://developercommunity.visualstudio.com/t/Intellisense-def-c-syntax-analys-erro/10152997?entry=myfeedback&ref=native&refTime=1663702331881&refUserId=af882232-2bec-6f74-8b90-a070b0b9e331

[sean-mcmanus]

@Bestie123 Okay, thanks, I've changed this issue to Tracking the VS issue.

[sean-mcmanus]

It looks like they fixed it with VS 17.6, but we don't have the fix, although we may in the future.

[Bestie123]

@sean-mcmanus, I have checked visual studio. Indeed, the problems have been fixed, so far there have been no serious problems. The exception is when you restart visual studio and select "show all links". The display may break and give out the wrong links or more than they actually are. This is sort of solved by choosing "show definition" then "show all links". Later I will inform the developers about this shortcoming. In vs code, the link search still breaks down and part of it just disappears. vs code uses exactly the new compiler since I reinstalled windows the other day and put all programs on clean. Also, the values in the .def file are now highlighted in turquoise, perhaps this indicates that a new compiler is being used. Previously, these words were not searched for in visual studio, now they are referenced in visual studio, but not in VS code. Finds something in the code, but it seems to also truncate the results