Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

function with the name "new" messes with folding and formatting #8381

Closed
stanle-cs opened this issue Nov 9, 2021 · 13 comments
Closed

function with the name "new" messes with folding and formatting #8381

stanle-cs opened this issue Nov 9, 2021 · 13 comments
Assignees
Labels
Language Service more info needed The issue report is not actionable in its current state Verifying - Internal Verifying if issue reproduces

Comments

@stanle-cs
Copy link

stanle-cs commented Nov 9, 2021

Issue Type: Bug

  • Enable C/C++ extension.

  • Create a function new() in a .c file (ANSI-C compiled with -ansi -pedantic):

void * new(const void * _class, ...)
{
}
  • These bugs appear:
    1. folding will fold at the { not at the void * new(…) line
    2. when pressing enter, the cursor will move to the first column, not keeping the indentation of the previous line

Extension version: 1.7.1
VS Code version: Code 1.62.1 (f4af3cbf5a99787542e2a30fe1fd37cd644cc31f, 2021-11-05T10:57:55.946Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No

Vc Format Setting
[*]
cpp_indent_braces=false
cpp_indent_multi_line_relative_to=innermost_parenthesis
cpp_indent_within_parentheses=indent
cpp_indent_preserve_within_parentheses=false
cpp_indent_case_labels=false
cpp_indent_case_contents=true
cpp_indent_case_contents_when_block=false
cpp_indent_lambda_braces_when_parameter=true
cpp_indent_goto_labels=one_left
cpp_indent_preprocessor=leftmost_column
cpp_indent_access_specifiers=false
cpp_indent_namespace_contents=true
cpp_indent_preserve_comments=false
cpp_new_line_before_open_brace_namespace=ignore
cpp_new_line_before_open_brace_type=new_line
cpp_new_line_before_open_brace_function=new_line
cpp_new_line_before_open_brace_block=new_line
cpp_new_line_before_open_brace_lambda=ignore
cpp_new_line_scope_braces_on_separate_lines=true
cpp_new_line_close_brace_same_line_empty_type=true
cpp_new_line_close_brace_same_line_empty_function=true
cpp_new_line_before_catch=true
cpp_new_line_before_else=true
cpp_new_line_before_while_in_do_while=false
cpp_space_before_function_open_parenthesis=remove
cpp_space_within_parameter_list_parentheses=false
cpp_space_between_empty_parameter_list_parentheses=false
cpp_space_after_keywords_in_control_flow_statements=true
cpp_space_within_control_flow_statement_parentheses=false
cpp_space_before_lambda_open_parenthesis=false
cpp_space_within_cast_parentheses=false
cpp_space_after_cast_close_parenthesis=true
cpp_space_within_expression_parentheses=false
cpp_space_before_block_open_brace=true
cpp_space_between_empty_braces=false
cpp_space_before_initializer_list_open_brace=false
cpp_space_within_initializer_list_braces=true
cpp_space_preserve_in_initializer_list=true
cpp_space_before_open_square_bracket=false
cpp_space_within_square_brackets=false
cpp_space_before_empty_square_brackets=false
cpp_space_between_empty_square_brackets=false
cpp_space_group_square_brackets=true
cpp_space_within_lambda_brackets=false
cpp_space_between_empty_lambda_brackets=false
cpp_space_before_comma=false
cpp_space_after_comma=true
cpp_space_remove_around_member_operators=true
cpp_space_before_inheritance_colon=true
cpp_space_before_constructor_colon=true
cpp_space_remove_before_semicolon=true
cpp_space_after_semicolon=false
cpp_space_remove_around_unary_operator=true
cpp_space_around_binary_operator=insert
cpp_space_around_assignment_operator=insert
cpp_space_pointer_reference_alignment=ignore
cpp_space_around_ternary_operator=insert
cpp_wrap_preserve_blocks=one_liners

Minimal c_cpp_properties.json to reproduce problem
{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "windowsSdkVersion": "10.0.22000.0",
            "compilerPath": "C:/msys64/mingw64/bin/gcc.exe",
            "cppStandard": "c++17",
            "intelliSenseMode": "windows-gcc-x64",
            "cStandard": "c17"
        }
    ],
    "version": 4
}
C/C++ diagnostics
-------- Diagnostics - 11/9/2021, 1:45:15 PM
Version: 1.7.1
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE"
    ],
    "windowsSdkVersion": "10.0.22000.0",
    "compilerPath": "C:/msys64/mingw64/bin/gcc.exe",
    "cppStandard": "c++17",
    "configurationProvider": "ms-vscode.cmake-tools",
    "intelliSenseMode": "windows-gcc-x64",
    "cStandard": "c17",
    "compilerPathIsExplicit": true,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "compilerArgs": [],
    "mergeConfigurations": false,
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Custom browse configuration: 
{
    "browsePath": [
        "c:/users/stanl/c_hierarchy_practice/build/cmakefiles",
        "c:/users/stanl/c_hierarchy_practice",
        "c:/users/stanl/c_hierarchy_practice/build/cmakefiles/3.20.21032501-msvc_2/compileridc"
    ],
    "compilerPath": "c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe",
    "compilerArgs": [
        "-pedantic",
        "-ansi",
        "-g"
    ]
}
Translation Unit Mappings:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\Object.c ]:
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\OBJECT.C
Translation Unit Configurations:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\Object.c ]:
    Process ID: 22492
    Memory Usage: 19 MB
    Compiler Path: c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe
    Includes:
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0\X86_64-W64-MINGW32
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0\BACKWARD
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE
        C:\MSYS64\MINGW64\INCLUDE
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE-FIXED
        C:\MSYS64\MINGW64\X86_64-W64-MINGW32\INCLUDE
    Standard Version: c++03
    IntelliSense Mode: windows-gcc-x64
    Other Flags:
        --g++
        --gnu_version=110200
Total Memory Usage: 19 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 3541
Number of files parsed: 144
System Info
Item Value
CPUs AMD Ryzen 9 3900X 12-Core Processor (24 x 3793)
GPU Status 2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
Load (avg) undefined
Memory (System) 63.94GB (56.41GB free)
Process Argv --crash-reporter-id af43cc5a-5c44-43fe-be96-e3d9c1e96370
Screen Reader no
VM 0%
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
vsccppwtct:30382698
bridge0708:30335490
pygetstartedt3:30385195
dockerwalkthru:30377721
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30391933
pythonvspyt187:30373474
vsqsis200cf:30386380
vsaa593:30376534
vssld246:30386377

@Colengms Colengms self-assigned this Nov 9, 2021
@Colengms
Copy link
Contributor

Colengms commented Nov 9, 2021

Hi @stanle-cs . I'm able to reproduce the folding issue in VS. (The C/C++ Extension shares code for various features with VS). I've opened a bug internally for that issue.

I'm not able to reproduce a formatting/indentation issue. Could you provide more info on how to reproduce that? Could you provide any formatting settings you have specified, as well as any VS Code settings you've set that refer to 'indent'?

@Colengms Colengms added Language Service more info needed The issue report is not actionable in its current state labels Nov 9, 2021
@stanle-cs
Copy link
Author

Hi @Colengms , I've updated the report with the format settings I'm using. I also forced the use of VcFormat as the formatting engine.

@Colengms
Copy link
Contributor

Colengms commented Nov 9, 2021

Also, I should mention that the diagnostics you provided indicates the file object.c is being treated as a C++ file, not a C file. A ".c" file should be treated as C, unless remapped using a files.associations setting. You may want to check your settings.json files or this incorrect association. Also, I don't believe the language specified to CMake influences what language VS Code associates with the file for editing purposes. (I don't see any feature to do this in the code to the CMake Tools extension).

@stanle-cs
Copy link
Author

@Colengms If that's the case then this should be another bug, I don't have any custom association settings for my project.
VS Code also claimed that it is reading a C file on the bottom right corner?
image

@Colengms
Copy link
Contributor

Colengms commented Nov 9, 2021

Hi @stanle-cs . I needed to enable editor.formatOnType, but was able to also reproduce the formatting issue. I've update the bug I opened internally to also cover the formatting issue.

@Colengms
Copy link
Contributor

Colengms commented Nov 9, 2021

Hi @stanle-cs . I'm not able to easily reproduce the incorrect language selection issue locally. I would need more information to determine why that is happening. Can you provide a stand-alone example I could use to investigate further? (Perhaps in the form of a git repo?)

The following indicators in the Log Diagnostics point to C++ being used when you collected that log:

    Standard Version: c++03
        --g++

Also, I do not see any "Custom configurations:" section in your Log Diagnostics output, so it would appear that the file was not configured by CMake Tools in that case. (Or, it had been configured according to the 'custom browse config', but a configuration for that specific file was not provided). Had you run CMake: Configure to ensure that CMake Tools has started providing configurations?

@stanle-cs
Copy link
Author

stanle-cs commented Nov 9, 2021

Hi @Colengms I tried to reproduce the bug itself too but could not consistently make it work. Basic idea is that, if I were to create a new project with a new main.h file and declare void * new(const void * _class, ...) in it it will be automatically associated with C++. When I then include the header file into my main.c it will then be treated as a C++ file too.

However this behavior seems pretty random since I tried to reproduce it a couple of times to no avail.

I have definitely had that happen to me before though, since now that you mention it, for a while the extension was giving me error wiggles with the error expected identifier whenever I define new(). That was the reason why I tried to use CMake's LANGUAGES C to "force" it into linting for C only. As you said it doesn't matter, I have no idea why it worked then. I had to run cmake.cleanConfigure occasionally to clear those error wiggles. It all makes sense now that VS Code is considering my file as C++ sources.

As for the lack of "Custom configurations:" section, I have no idea why that's the case. I used a key binding to map cmake.cleanConfigure and use that to configure the new project. Seems like I need to explicitly run the CMake: Configure.

Here's a repo with the codes I'm working with, hopefully you can trigger the bug with these files occasionally: Association Bug

@Colengms Colengms added the To Verify - Internal To verify if issue reproduces label Nov 10, 2021
@v-ericawu v-ericawu added Verifying - Internal Verifying if issue reproduces and removed To Verify - Internal To verify if issue reproduces labels Nov 11, 2021
@stanle-cs
Copy link
Author

stanle-cs commented Nov 14, 2021

Got the bug that parse .c file as C++ source again. This time I can reproduce it. Create a new project, don't run CMAKE: Configure . Then simply create a new file .c, the file will be parsed as C++ source. (uploaded these files onto the git repo so you can check it out)

EDIT: even after running CMake: configure the error still remains if you create a new .c file. You need to run CMake: configure every time you create a new source file for it to be recognized as C source.

C/C++ diagnostic
-------- Diagnostics - 11/13/2021, 10:15:04 PM
Version: 1.7.1
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE"
    ],
    "windowsSdkVersion": "10.0.22000.0",
    "compilerPath": "C:/msys64/mingw64/bin/gcc.exe",
    "cppStandard": "c++17",
    "configurationProvider": "ms-vscode.cmake-tools",
    "intelliSenseMode": "windows-gcc-x64",
    "cStandard": "c17",
    "compilerPathIsExplicit": true,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "compilerArgs": [],
    "mergeConfigurations": false,
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Custom browse configuration: 
{
    "browsePath": [
        "c:/users/stanl/c_hierarchy_practice/build/cmakefiles",
        "c:/users/stanl/c_hierarchy_practice",
        "c:/users/stanl/c_hierarchy_practice/build/cmakefiles/3.20.21032501-msvc_2/compileridc"
    ],
    "compilerPath": "c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe",
    "compilerArgs": [
        "-pedantic",
        "-ansi",
        "-g"
    ]
}
Custom configurations:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\Point.c ]
{
    "defines": [],
    "includePath": [],
    "compilerPath": "c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe",
    "compilerArgs": [
        "-pedantic",
        "-ansi",
        "-g"
    ]
}
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\Object.c ]
{
    "defines": [],
    "includePath": [],
    "compilerPath": "c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe",
    "compilerArgs": [
        "-pedantic",
        "-ansi",
        "-g"
    ]
}
Translation Unit Mappings:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\Point.c ]:
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\POINT.C
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\POINT.H
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\POINT_STRUCT.H
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\OBJECT.H
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\Object.c ]:
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\OBJECT.C
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\OBJECT.H
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\test.c ]:
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\TEST.C
Translation Unit Configurations:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\Point.c ]:
    Process ID: 5300
    Memory Usage: 19 MB
    Compiler Path: c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe
    Includes:
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE
        C:\MSYS64\MINGW64\INCLUDE
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE-FIXED
        C:\MSYS64\MINGW64\X86_64-W64-MINGW32\INCLUDE
    Standard Version: c17
    IntelliSense Mode: windows-gcc-x64
    Other Flags:
        --gcc
        --gnu_version=110200
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\Object.c ]:
    Process ID: 10104
    Memory Usage: 19 MB
    Compiler Path: c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe
    Includes:
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE
        C:\MSYS64\MINGW64\INCLUDE
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE-FIXED
        C:\MSYS64\MINGW64\X86_64-W64-MINGW32\INCLUDE
    Standard Version: c17
    IntelliSense Mode: windows-gcc-x64
    Other Flags:
        --gcc
        --gnu_version=110200
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\test.c ]:
    Process ID: 1648
    Memory Usage: 18 MB
    Compiler Path: c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe
    Includes:
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0\X86_64-W64-MINGW32
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0\BACKWARD
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE
        C:\MSYS64\MINGW64\INCLUDE
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE-FIXED
        C:\MSYS64\MINGW64\X86_64-W64-MINGW32\INCLUDE
    Standard Version: c++03
    IntelliSense Mode: windows-gcc-x64
    Other Flags:
        --g++
        --gnu_version=110200
Total Memory Usage: 56 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 3540
Number of files parsed: 32

@Colengms
Copy link
Contributor

Hi @stanle-cs . I think I might know what's happening.

If you had previously run Configure in a previous session, the C/C++ Extension will preserve the 'browse configuration' provided by the configuration provider (CMake Tools). That browse configuration is basically a config to fall back to when a configuration is not available for a particular file, and is based on compiler options configured in CMakeLists.txt that are not file-specific. I believe CMake Tools will not respond with configurations for specific files until Configure is run in the current session. In the cases in which you were getting the wrong language, I think it was based on the preserved 'browse configuration'.

There are currently some limitations of the custom browse configuration. It provides a compiler path, compiler args, and a standard version, but only for one language, C or C++.

That said, I don't see a 'standard' included in your browse configuration at all. You should be able to get this process to default to C instead of C++ by specify the language standard version to CMake, either using something like set(CMAKE_C_STANDARD 99), or by specifying the language standard version as a compiler argument using add_compile_options.

If this is indeed what is happening, let me know, and we can convert this issue into a request to improve the custom browse configuration such that it includes sufficient information for configuring both C and C++ sources properly.

@stanle-cs
Copy link
Author

stanle-cs commented Nov 18, 2021

Hi @Colengms , sorry for the late reply.

EDIT: I realized that whenever I change the name of a source file the same error will also show up until I rerun configure.

Here's the situation I'm having (hopefully you can duplicate the same behavior using the git repo).

  • Run CMAKE: Delete Cache and Reconfigure on this workspace. All files currently in the included path will be considered C source.
  • Create a new .h file, for example Test.h, and this file will be considered C++ source until I re-run CMAKE: Configure.
  • After I added set(CMAKE_C_STANDARD 99) to the CMakeList.txt file I have this error thrown command-line error: language modes specified are incompatibleC/C++(1027)
-------- Diagnostics - 11/18/2021, 9:49:56 AM
Version: 1.7.1
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE"
    ],
    "windowsSdkVersion": "10.0.22000.0",
    "compilerPath": "C:/msys64/mingw64/bin/gcc.exe",
    "cppStandard": "c++17",
    "configurationProvider": "ms-vscode.cmake-tools",
    "intelliSenseMode": "windows-gcc-x64",
    "cStandard": "c17",
    "compilerPathIsExplicit": true,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "compilerArgs": [],
    "mergeConfigurations": false,
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Custom browse configuration: 
{
    "browsePath": [
        "c:/users/stanl/c_hierarchy_practice/build/cmakefiles",
        "c:/users/stanl/c_hierarchy_practice",
        "c:/users/stanl/c_hierarchy_practice/subclasses"
    ],
    "standard": "gnu99",
    "compilerPath": "c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe",
    "compilerArgs": [
        "-g",
        "-std=gnu99"
    ]
}
Translation Unit Mappings:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\subclasses\Test_struct_test.h ]:
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\SUBCLASSES\TEST_STRUCT_TEST.H
Translation Unit Configurations:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\subclasses\Test_struct_test.h ]:
    Process ID: 8676
    Memory Usage: 13 MB
    Compiler Path: c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe
    Includes:
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE
        C:\MSYS64\MINGW64\INCLUDE
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE-FIXED
        C:\MSYS64\MINGW64\X86_64-W64-MINGW32\INCLUDE
    Standard Version: c++17
    IntelliSense Mode: windows-gcc-x64
    Other Flags:
        --gcc
        --gnu_version=110200
        --header_only_fallback
Total Memory Usage: 13 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 3629

It is now even weirder because the standard used is c++17 but the flags are set to gcc!

I therefore have to rerun Configure every time a new file is created in the workspace.
Updated the git repo, step to reproduce:

  • Open the workspace
  • Run CMAKE: Delete Cache and Reconfigure
  • Create a new file named "Test.h"

Here's a C/C++ diagnostics when I create a new Test_struct.h without the set(CMAKE_C_STANDARD 99) :

-------- Diagnostics - 11/18/2021, 9:42:37 AM
Version: 1.7.1
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE"
    ],
    "windowsSdkVersion": "10.0.22000.0",
    "compilerPath": "C:/msys64/mingw64/bin/gcc.exe",
    "cppStandard": "c++17",
    "configurationProvider": "ms-vscode.cmake-tools",
    "intelliSenseMode": "windows-gcc-x64",
    "cStandard": "c17",
    "compilerPathIsExplicit": true,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "compilerArgs": [],
    "mergeConfigurations": false,
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Custom browse configuration: 
{
    "browsePath": [
        "c:/users/stanl/c_hierarchy_practice/build/cmakefiles",
        "c:/users/stanl/c_hierarchy_practice"
    ],
    "compilerPath": "c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe",
    "compilerArgs": [
        "-g"
    ]
}
Translation Unit Mappings:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\subclasses\Test_struct.h ]:
    C:\USERS\STANL\C_HIERARCHY_PRACTICE\SUBCLASSES\TEST_STRUCT.H
Translation Unit Configurations:
[ C:\Users\stanl\C_HIERARCHY_PRACTICE\subclasses\Test_struct.h ]:
    Process ID: 1740
    Memory Usage: 18 MB
    Compiler Path: c:/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe
    Includes:
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0\X86_64-W64-MINGW32
        C:\MSYS64\MINGW64\INCLUDE\C++\11.2.0\BACKWARD
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE
        C:\MSYS64\MINGW64\INCLUDE
        C:\MSYS64\MINGW64\LIB\GCC\X86_64-W64-MINGW32\11.2.0\INCLUDE-FIXED
        C:\MSYS64\MINGW64\X86_64-W64-MINGW32\INCLUDE
    Standard Version: c++17
    IntelliSense Mode: windows-gcc-x64
    Other Flags:
        --g++
        --gnu_version=110200
        --header_only_fallback
Total Memory Usage: 18 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 3630

@Colengms
Copy link
Contributor

Hi @stanle-cs . I think you have uncovered a couple of bugs here, and I've got fixes that should make it into the next release.

When you first create a header file, and it's not yet included in any source files, the header is treated as C++ by default by VS Code. You could change that behavior with the following setting:

	"files.associations": {
		"*.h": "c"
        }

Does that work around your immediate issue?

A custom configuration provider provides configurations for source file, but is not aware of header files. Once a source file includes the header, the header should be interpreted as the same language as the source file. (If multiple files include the header, and some are C and others C++, it will pick one). I did find a couple of bugs around this logic (around when the original source file the header was associated with gets closed), which we will fix.

@bobbrow
Copy link
Member

bobbrow commented Nov 19, 2021

A custom configuration provider provides configurations for source file, but is not aware of header files.

CMake Tools is capable of providing configurations for headers if the headers are added to the executable/library target in your CMakeLists.txt. We do it for our build of cpptools, but I don't think it's common practice.

I thought that cpptools avoids asking for header configurations by doing the header->source map lookup first though. So there would be fewer cases where a request for a header configuration would actually happen.

@github-actions
Copy link

This issue has been closed automatically because it needs more information and has not had recent activity.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Language Service more info needed The issue report is not actionable in its current state Verifying - Internal Verifying if issue reproduces
Projects
None yet
Development

No branches or pull requests

4 participants