vscode-cpptools cpptools goto framework headers error

Environment

Version: 1.102.3 Commit: 488a1f239235055e34e673291fb8d8c810886f81 Date: 2025-07-29T03:00:23.339Z Electron: 35.6.0 ElectronBuildId: 11847422 Chromium: 134.0.6998.205 Node.js: 22.15.1 V8: 13.4.114.21-electron.0 OS: Darwin x64 23.6.0

-------- Diagnostics - 2025/10/12 11:38:35 Version: 1.26.5 Current Configuration: { "name": "Mac", "includePath": [ "/Users/admin/Desktop/qt-test/" ], "defines": [], "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "macos-clang-x64", "intelliSenseModeIsExplicit": false, "cStandardIsExplicit": false, "cppStandardIsExplicit": false, "mergeConfigurations": false, "recursiveIncludes": {}, "recursiveIncludesReduceIsExplicit": false, "recursiveIncludesPriorityIsExplicit": false, "recursiveIncludesOrderIsExplicit": false, "compilerPath": "/usr/bin/clang++", "compilerPathIsExplicit": true, "configurationProvider": "ms-vscode.cmake-tools", "browse": { "limitSymbolsToIncludedHeaders": true } } Modified Settings: { "C_Cpp.default.compilerPath": "/usr/bin/clang++" } Additional Tracked Settings: { "editorTabSize": 4, "editorInsertSpaces": true, "editorAutoClosingBrackets": "languageDefined", "filesEncoding": "utf8", "filesAssociations": { ".cpp": "cpp", ".qrc": "xml", "qmainwindow": "cpp", "qmessagebox": "cpp" }, "filesExclude": { "/.git": true, "/.svn": true, "/.hg": true, "/.DS_Store": true, "/Thumbs.db": true }, "filesAutoSaveAfterDelay": false, "editorInlayHintsEnabled": true, "editorParameterHintsEnabled": true, "searchExclude": { "/node_modules": true, "/bower_components": true, "**/*.code-search": true }, "workbenchSettingsEditor": "ui" } Custom browse configuration: { "browsePath": [ "/Users/admin/Desktop/qt-test-build/CMakeFiles", "/Users/admin/Desktop/qt-test-build", "/Users/admin/Desktop/qt-test-build/qt-test_autogen/include", "/Users/admin/Qt/6.7.2/macos/lib/QtCore.framework/Headers", "/Users/admin/Qt/6.7.2/macos/mkspecs/macx-clang", "/Users/admin/Qt/6.7.2/macos/include", "/Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers", "/Users/admin/Qt/6.7.2/macos/lib/QtGui.framework/Headers", "/Users/admin/Desktop/qt-test", "/Users/admin/Qt/6.7.2/macos/lib", "/Users/admin/Desktop/qt-test-build/qt-test_autogen", "/Users/admin/Desktop/qt-test-build/.qt/rcc" ], "compilerPath": "/usr/bin/clang++", "compilerArgs": [], "compilerFragments": [ "-g -std=gnu++17 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk" ] } cpptools version (native): 1.26.4.0 Current database path: /Users/admin/Library/Caches/vscode-cpptools/45ab2c909f9b34cdcc4ccd8e6f09dab9/.browse.VC.db Translation Unit Mappings: [ /Users/admin/Desktop/qt-test/main.cpp - source TU]: /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers/qmainwindow.h Translation Unit Configurations: [ /Users/admin/Desktop/qt-test/main.cpp ] Process ID: 7263 Memory Usage: 15 MB Compiler Path: /usr/bin/clang++ Include paths: include: /Users/admin/Desktop/qt-test-build/qt-test_autogen/include include: /Users/admin/Qt/6.7.2/macos/lib/QtCore.framework/Headers include: /Users/admin/Qt/6.7.2/macos/mkspecs/macx-clang include: /Users/admin/Qt/6.7.2/macos/include include: /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers include: /Users/admin/Qt/6.7.2/macos/lib/QtGui.framework/Headers include: /Users/admin/Qt/6.7.2/macos/lib system include: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/usr/include/c++/v1 system include: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include system include: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/usr/include system include: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include system framework search path (default): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/System/Library/Frameworks Defines: QT_CORE_LIB QT_GUI_LIB QT_WIDGETS_LIB Standard Version: c++17 IntelliSense Mode: macos-clang-x64 Other Flags: --clang --clang_version=160000 Total Memory Usage: 15 MB

------- Workspace parsing diagnostics ------- Number of files discovered (not excluded): 18218 Number of files parsed: 1429

my main.cpp use #include <QApplication> can goto /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers/QApplication but if I use #include <QtWidgets/QApplication> can't goto the file cpptools not trans <QtWidgets/QApplication> to /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers/QApplication, not find the file

but qt have many internal file use <framework/header.h>

(i.e. #include <OpenGLES/ES2/gl.h>, mapping to OpenGLES.framework/Headers/ES2/gl.h).

Bug Summary and Steps to Reproduce

Bug Summary:

Steps to reproduce:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior:

Configuration and Logs

-------- Diagnostics - 2025/10/12 11:38:35
Version: 1.26.5
Current Configuration:
{
    "name": "Mac",
    "includePath": [
        "/Users/admin/Desktop/qt-test/**"
    ],
    "defines": [],
    "cStandard": "c17",
    "cppStandard": "c++17",
    "intelliSenseMode": "macos-clang-x64",
    "intelliSenseModeIsExplicit": false,
    "cStandardIsExplicit": false,
    "cppStandardIsExplicit": false,
    "mergeConfigurations": false,
    "recursiveIncludes": {},
    "recursiveIncludesReduceIsExplicit": false,
    "recursiveIncludesPriorityIsExplicit": false,
    "recursiveIncludesOrderIsExplicit": false,
    "compilerPath": "/usr/bin/clang++",
    "compilerPathIsExplicit": true,
    "configurationProvider": "ms-vscode.cmake-tools",
    "browse": {
        "limitSymbolsToIncludedHeaders": true
    }
}
Modified Settings:
{
    "C_Cpp.default.compilerPath": "/usr/bin/clang++"
}
Additional Tracked Settings:
{
    "editorTabSize": 4,
    "editorInsertSpaces": true,
    "editorAutoClosingBrackets": "languageDefined",
    "filesEncoding": "utf8",
    "filesAssociations": {
        "*.cpp": "cpp",
        "*.qrc": "xml",
        "qmainwindow": "cpp",
        "qmessagebox": "cpp"
    },
    "filesExclude": {
        "**/.git": true,
        "**/.svn": true,
        "**/.hg": true,
        "**/.DS_Store": true,
        "**/Thumbs.db": true
    },
    "filesAutoSaveAfterDelay": false,
    "editorInlayHintsEnabled": true,
    "editorParameterHintsEnabled": true,
    "searchExclude": {
        "**/node_modules": true,
        "**/bower_components": true,
        "**/*.code-search": true
    },
    "workbenchSettingsEditor": "ui"
}
Custom browse configuration: 
{
    "browsePath": [
        "/Users/admin/Desktop/qt-test-build/CMakeFiles",
        "/Users/admin/Desktop/qt-test-build",
        "/Users/admin/Desktop/qt-test-build/qt-test_autogen/include",
        "/Users/admin/Qt/6.7.2/macos/lib/QtCore.framework/Headers",
        "/Users/admin/Qt/6.7.2/macos/mkspecs/macx-clang",
        "/Users/admin/Qt/6.7.2/macos/include",
        "/Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers",
        "/Users/admin/Qt/6.7.2/macos/lib/QtGui.framework/Headers",
        "/Users/admin/Desktop/qt-test",
        "/Users/admin/Qt/6.7.2/macos/lib",
        "/Users/admin/Desktop/qt-test-build/qt-test_autogen",
        "/Users/admin/Desktop/qt-test-build/.qt/rcc"
    ],
    "compilerPath": "/usr/bin/clang++",
    "compilerArgs": [],
    "compilerFragments": [
        "-g -std=gnu++17 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk"
    ]
}
cpptools version (native): 1.26.4.0
Current database path: /Users/admin/Library/Caches/vscode-cpptools/45ab2c909f9b34cdcc4ccd8e6f09dab9/.browse.VC.db
Translation Unit Mappings:
[ /Users/admin/Desktop/qt-test/main.cpp - source TU]:
    /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers/qmainwindow.h
Translation Unit Configurations:
[ /Users/admin/Desktop/qt-test/main.cpp ]
    Process ID: 7263
    Memory Usage: 15 MB
    Compiler Path: /usr/bin/clang++
    Include paths:
        include: /Users/admin/Desktop/qt-test-build/qt-test_autogen/include
        include: /Users/admin/Qt/6.7.2/macos/lib/QtCore.framework/Headers
        include: /Users/admin/Qt/6.7.2/macos/mkspecs/macx-clang
        include: /Users/admin/Qt/6.7.2/macos/include
        include: /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers
        include: /Users/admin/Qt/6.7.2/macos/lib/QtGui.framework/Headers
        include: /Users/admin/Qt/6.7.2/macos/lib
        system include: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/usr/include/c++/v1
        system include: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/include
        system include: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/usr/include
        system include: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
        system framework search path (default): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk/System/Library/Frameworks
    Defines:
        QT_CORE_LIB
        QT_GUI_LIB
        QT_WIDGETS_LIB
    Standard Version: c++17
    IntelliSense Mode: macos-clang-x64
    Other Flags:
        --clang
        --clang_version=160000
Total Memory Usage: 15 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 18218
Number of files parsed: 1429

Other Extensions

No response

Additional context

No response

Oct 12 '25 03:10 debugee

@debugee You have framework paths being specified as an include instead of as a framework path. Can you try setting macFrameworkPath? However, if you're using CMake Tools, you may need to configure that to send the frameworks.

Oct 13 '25 18:10 sean-mcmanus

Support for mac frameworks was added to CMake Tools a while ago. https://github.com/microsoft/vscode-cmake-tools/pull/3247. Though it does require a recent version of CMake. Setting a mac framework path in the include path is supposed to work (or maybe I'm confusing that with the tag parser configuration which I know for sure handles it).

include: /Users/admin/Qt/6.7.2/macos/lib - This is the framework path which is showing up in the include path instead of the framework path. (Again, I thought that IntelliSense could handle it this way though)

#include <QtWidgets/QApplication> is the correct way to use the framework headers, so once we determine that the configuration issue is solved, we can figure out if there are still issues with go to definition or the red squiggles.

Oct 13 '25 18:10 bobbrow

#include < QApplication > (include framework header method like this we call it M1) #include <QtWidgets/QApplication> (include framework header method like this we call it M2)

https://github.com/microsoft/vscode-cmake-tools/pull/3247 not solve M2

clang compile the source file with M2 or M1 is all ok

clang compiler flag -iframework /Users/admin/Qt/6.7.2/macOS/lib for find M2 clang compiler flag -isystem /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers for find M1

1、clang -std=gnu++17 -c mainwindow.cpp -isystem /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers -iframework /Users/admin/Qt/6.7.2/macOS/lib 2、clang -std=gnu++17 -c mainwindow.cpp -iframework /Users/admin/Qt/6.7.2/macOS/lib 3、clang -std=gnu++17 -c mainwindow.cpp -isystem /Users/admin/Qt/6.7.2/macos/lib/QtWidgets.framework/Headers

1、compile ok 2、compile not find QMainWindow 3、compile not find QtWidgets/qtwidgetsglobal.h

also see https://github.com/microsoft/vscode-cpptools/issues/13204

Oct 14 '25 00:10 debugee

Support for mac frameworks was added to CMake Tools a while ago. https://github.com/microsoft/vscode-cmake-tools/pull/3247. Though it does require a recent version of CMake. Setting a mac framework path in the include path is supposed to work (or maybe I'm confusing that with the tag parser configuration which I know for sure handles it).

include: /Users/admin/Qt/6.7.2/macos/lib - This is the framework path which is showing up in the include path instead of the framework path. (Again, I thought that IntelliSense could handle it this way though)

#include <QtWidgets/QApplication> is the correct way to use the framework headers, so once we determine that the configuration issue is solved, we can figure out if there are still issues with go to definition or the red squiggles.

这应该是个bug吧？cpptools应该通过编译参数自动实现goto，而不是需要添加浏览路径或者include路径，而且路径已经被cmaketools自动添加了，请你确认一下这个问题，很影响我的体验

Oct 15 '25 16:10 debugee

@bobbrow @sean-mcmanus cmake-tools把framework当includes使用了

而且你说的这个https://github.com/microsoft/vscode-cmake-tools/pull/3247 并没有解决#include <QtWidgets/QMessageBox>这种方式,因为丢失了framework路径我手动添加target_compile_options(qt-test PRIVATE -iframework/users/admin/qt/6.7.2/macos/lib) 就好了,但是cpptools有一个致命的问题, QMessageBox 文件无后缀,导致进一步goto的时候,cpptools把QMessageBox当源文件使用了也就是translate unit 已经改变了

而且分开处理includes和flags中的include设置,会导致严重的优先级紊乱 https://github.com/microsoft/vscode-cmake-tools/issues/4597

这不仅仅是cmake-tools的问题,设计上都有问题,分开处理包含路径就会丢失优先级

Oct 19 '25 13:10 debugee

@bobbrow @sean-mcmanus

https://github.com/debugee/bug-sample

cmake_minimum_required(VERSION 3.30)

set(CMAKE_VERBOSE_MAKEFILE ON)

project(sample VERSION 0.1 LANGUAGES C CXX)

add_executable(sample sample.cpp )

add_library(dynamicFramework SHARED dynamicFramework.cpp dynamicFramework.h )

set_target_properties(dynamicFramework PROPERTIES FRAMEWORK TRUE SYSTEM TRUE PUBLIC_HEADER dynamicFramework.h )

#when dynamicFramework is framework target, cmake will add -F<path_to_dynamicFramework> to sample CXX_INCLUDES #when SYSTEM is TRUE, cmake will add -iframework <path_to_dynamicFramework> to sample CXX_INCLUDES target_link_libraries(sample PRIVATE dynamicFramework)

target_compile_options(sample PRIVATE -v)

target_include_directories(sample PRIVATE test/A)

target_include_directories(sample PRIVATE test/B/b.framework)

target_include_directories(sample PRIVATE test/C)

target_include_directories(sample SYSTEM PRIVATE test/E)

target_compile_options(sample PRIVATE -I${CMAKE_CURRENT_SOURCE_DIR}/test/D)

############################# clang -v [build] /Users/admin/Desktop/bug-sample/test/A [build] /Users/admin/Desktop/bug-sample/test/B (framework directory) [build] /Users/admin/Desktop/bug-sample/test/C [build] /Users/admin/Desktop/bug-sample/test/D [build] /Users/admin/Desktop/bug-sample/test/E [build] /Users/admin/Desktop/bug-sample/build (framework directory) [build] /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/usr/include/c++/v1 [build] /Library/Developer/CommandLineTools/usr/lib/clang/16/include [build] /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/usr/include [build] /Library/Developer/CommandLineTools/usr/include [build] /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/System/Library/Frameworks (framework directory)

cmake fileapi { "compileCommandFragments" : [ { "fragment" : "-g -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk -mmacosx-version-min=14.6" }, { "backtrace" : 3, "fragment" : "-v" }, { "backtrace" : 4, "fragment" : "-I/Users/admin/Desktop/bug-sample/test/D" } ], "frameworks" : [ { "backtrace" : 6, "path" : "/Users/admin/Desktop/bug-sample/test/B/b.framework" }, { "isSystem" : true, "path" : "/Users/admin/Desktop/bug-sample/build/dynamicFramework.framework" } ], "includes" : [ { "backtrace" : 5, "path" : "/Users/admin/Desktop/bug-sample/test/A" }, { "backtrace" : 7, "path" : "/Users/admin/Desktop/bug-sample/test/C" }, { "backtrace" : 8, "isSystem" : true, "path" : "/Users/admin/Desktop/bug-sample/test/E" } ] }

cmake-tools configurations { "uri": "file:///Users/admin/Desktop/bug-sample/sample.cpp", "configuration": { "includePath": [ "/Users/admin/Desktop/bug-sample/test/A", "/Users/admin/Desktop/bug-sample/test/C", "/Users/admin/Desktop/bug-sample/test/E", "/Users/admin/Desktop/bug-sample/test/B", "/Users/admin/Desktop/bug-sample/build" ], "defines": [], "compilerPath": "/usr/bin/clang++", "compilerArgs": [], "compilerFragments": [ "-g -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk -mmacosx-version-min=14.6", "-v", "-I/Users/admin/Desktop/bug-sample/test/D" ] } }

cpptools configurations Translation Unit Mappings: [ /Users/admin/Desktop/bug-sample/sample.cpp - source TU]: Translation Unit Configurations: [ /Users/admin/Desktop/bug-sample/sample.cpp ] Process ID: 15372 Memory Usage: 200 MB Compiler Path: /usr/bin/clang++ Include paths: include: /Users/admin/Desktop/bug-sample/test/A include: /Users/admin/Desktop/bug-sample/test/C include: /Users/admin/Desktop/bug-sample/test/E include: /Users/admin/Desktop/bug-sample/test/B include: /Users/admin/Desktop/bug-sample/build include: /Users/admin/Desktop/bug-sample/test/D system include: /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/usr/include/c++/v1 system include: /Library/Developer/CommandLineTools/usr/lib/clang/16/include system include: /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/usr/include system include: /Library/Developer/CommandLineTools/usr/include system framework search path (default): /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk/System/Library/Frameworks Standard Version: c++17 IntelliSense Mode: macos-clang-x64 Other Flags: --clang --clang_version=170006 Total Memory Usage: 200 MB

1、priority information lost !!! B(-F) 、 D(-I) 2、framework directories are treated as normal include directories !!! cmake-tools bug

if cmake-tools normal work with framework dir with macFrameworkPath setting how cpptools do test/D and test/B priority ?? test/B use -F must before test/D /build use -iframework must after test/D

cpptols have no information to distinguish

Oct 20 '25 13:10 debugee

The IntelliSense should allow for frameworks directories to be added to the normal include directories. I believe CMake Tools does this because there was a limitation of the API it uses to communicate with the C++ extension. It is documented as being supported.

We have a test that covers this scenario and I'm not aware of it failing recently. Unfortunately, I don't have a mac to test this with right now. @sean-mcmanus would you be able to look at this?

Oct 20 '25 16:10 bobbrow

@bobbrow Sure.

Oct 20 '25 16:10 sean-mcmanus

Hi @debugee . We're working on a fix for this. In the meanwhile, it should be possible to work around the issue by configuring CMake to generate a compile_commands.json file (using CMAKE_EXPORT_COMPILE_COMMANDS), and configuring IntelliSense to use that file to configure your project, using something like the following in your c_cpp_properties.json file:

"compileCommands": "${workspaceFolder}/build/compile_commands.json"

Oct 20 '25 21:10 Colengms

Hi @debugee . We're working on a fix for this. In the meanwhile, it should be possible to work around the issue by configuring CMake to generate a compile_commands.json file (using CMAKE_EXPORT_COMPILE_COMMANDS), and configuring IntelliSense to use that file to configure your project, using something like the following in your c_cpp_properties.json file:
"compileCommands": "${workspaceFolder}/build/compile_commands.json"

no body want do this， people want cmake-tools auto config by provider

Oct 20 '25 21:10 debugee

sourceFileConfiguare function look like support system directory and framework，but if have compiler and compile options like -I ， cpptools do not known where it insert to this include list，include list can have user system directory，framework dir can use postfix（.framework） to known insert it before

Oct 20 '25 22:10 debugee

no body want do this， people want cmake-tools auto config by provider

Yes, we understand that. @Colengms knows how to fix this but was giving you a temporary workaround if you need this to work today. It may be several days before we publish the correct fix.

Oct 20 '25 23:10 bobbrow

I suggest that cmake fileapi does not separate the framework directory from includes into frameworks, so that includes contains all directories, including those included by -I, -F, -iframework, -isystem, etc., because this can retain the priority information, so that when cmake-tools delivers these includes to cpptools, cpptools can insert other directory settings in the compilation command into the correct priority position. If frameworks and includes are processed separately, even if cmake-tools sets the correct parameters to cpptools.cpptools may not know that there is a framework directory with a high priority -F setting in frameworks. Putting the directories together can not only retain the priority information, but cpptools can also determine whether the directory suffix is ".framework" to confirm whether it is a framework directory. Cmake itself also determines whether the directory is a framework in this way, so that cpptools can find the framework header file in a standard way (#include <frameworkname/headername.h>), rather than adding a directory like this (/path/to/MyFramework.framework/Headers) to includes.

Thus, CMake's separation is incorrect; it should be combined, and the directories should be tracked, including system and framework directories (identifiable by the suffix), iframework directories, and regular directories. Therefore, the handling described in https://gitlab.kitware.com/cmake/cmake/-/issues/19897 is incorrect, and CMake-Tools's direct addition of frameworks to includes is even more incorrect. CppTools also needs improvement, as it's unaware of the high-priority framework directory and the system directory within includes, and thus doesn't know how to insert the directories specified later in the command into the correct locations.

Oct 21 '25 13:10 debugee

@Colengms You can never fix this because cmake and cmake-tools have lost the precedence of directories, and the interface does not pass a flag indicating whether it is a system directory.

Oct 22 '25 15:10 debugee

The C/C++ Extension component of this has been fixed such that it works as designed. The remaining issues would need to be addressed in CMake Tools.

Oct 22 '25 18:10 Colengms

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.29.0 (pre-release) ...not counting the issues that needs to be fixed by the configuration providers.

Nov 04 '25 23:11 sean-mcmanus

how to verify ? Are there any repair details?

Nov 05 '25 11:11 debugee

@debugee You can run C/C++: Log Diagnostics to see if the framework paths are correctly picked up as framework paths instead of normal include paths. After switching to the pre-release channel for 1.29.0.

Nov 05 '25 11:11 sean-mcmanus

@debugee You can run C/C++: Log Diagnostics to see if the framework paths are correctly picked up as framework paths instead of normal include paths. After switching to the pre-release channel for 1.29.0.

is includes field support test/B/b.framework ? or must add it to macFrameworkPath

Nov 06 '25 07:11 debugee

@debugee You can run C/C++: Log Diagnostics to see if the framework paths are correctly picked up as framework paths instead of normal include paths. After switching to the pre-release channel for 1.29.0.

It seems that it has not been repaired.

I know that cmake-tools input incorrect includes. Even if I treat them includes, there are still bugs in the subsequent path processing.

Please use the latest https://github.com/debugee/bug-sample.git

================================================================================= build] clang -cc1 version 17.0.0 (clang-1700.3.19.1) default target x86_64-apple-darwin24.6.0 [build] ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include" [build] ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks" [build] #include "..." search starts here: [build] #include <...> search starts here: [build] /Users/admin/Desktop/bug-sample/test/A [build] /Users/admin/Desktop/bug-sample/test/B (framework directory) [build] /Users/admin/Desktop/bug-sample/test/C [build] /Users/admin/Desktop/bug-sample/test/D [build] /usr/local/include [build] /Users/admin/Desktop/bug-sample/test/E [build] /Users/admin/Desktop/bug-sample/test/F [build] /Users/admin/Desktop/bug-sample/build (framework directory) [build] /Users/admin/Desktop/bug-sample/test/G (framework directory) [build] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1 [build] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include [build] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include [build] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include [build] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory) [build] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/SubFrameworks (framework directory) [build] End of search list. **============================================================ Above is the correct search path of clang, and the includes field passed by cmake-tools is "/Users/admin/Desktop/bug-sample/test/A", "/Users/admin/Desktop/bug-sample/test/C", "/Users/admin/Desktop/bug-sample/test/E", "/Users/admin/Desktop/bug-sample/test/B", "/Users/admin/Desktop/bug-sample/build",

The following is the path of cpptools. There is still an error.

1. Path test/G is lost

2. /test/F is behind the framework

3. How to decide that build directory is a framework? The suffix build/dynamicFramework.framework has been delete in includes. =============================================================** Custom browse configuration: { "browsePath": [ "/Users/admin/Desktop/bug-sample", "/Users/admin/Desktop/bug-sample/test/A", "/Users/admin/Desktop/bug-sample/test/C", "/Users/admin/Desktop/bug-sample/test/E", "/Users/admin/Desktop/bug-sample/test/B", "/Users/admin/Desktop/bug-sample/build" ], "compilerPath": "/usr/bin/clang++", "compilerArgs": [], "compilerFragments": [ "-g", "-v", "-I/Users/admin/Desktop/bug-sample/test/D", "-iframework/Users/admin/Desktop/bug-sample/test/G", "-isystem/Users/admin/Desktop/bug-sample/test/F" ] } cpptools version (native): 1.29.0.0 Current database path: /Users/admin/Library/Caches/vscode-cpptools/685053b2341a791a38afa23bb515c719/.browse.VC.db Translation Unit Mappings: [ /Users/admin/Desktop/bug-sample/sample.cpp - source TU]: Translation Unit Configurations: [ /Users/admin/Desktop/bug-sample/sample.cpp ] Process ID: 22269 Memory Usage: 168 MB Compiler Path: /usr/bin/clang++ Include paths: include: /Users/admin/Desktop/bug-sample/test/A include: /Users/admin/Desktop/bug-sample/test/C include: /Users/admin/Desktop/bug-sample/test/E include: /Users/admin/Desktop/bug-sample/test/B include: /Users/admin/Desktop/bug-sample/build framework search path: /Users/admin/Desktop/bug-sample/build include: /Users/admin/Desktop/bug-sample/test/D system include (isystem): /Users/admin/Desktop/bug-sample/test/F system include: /usr/local/include system include: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1 system include: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include system include: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include system include: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include system framework search path (default): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks system framework search path (default): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/SubFrameworks Standard Version: c++14 IntelliSense Mode: macos-clang-x64 Other Flags: --clang --clang_version=190104 Total Memory Usage: 168 MB

------- Workspace parsing diagnostics ------- Number of files discovered (not excluded): 12262 Number of files parsed: 2342

Nov 06 '25 07:11 debugee

@debugee Yes, the path is checked for child directories that match what we expect for a framework directory, so if you deleted a directory ending with .framework then we won't detect it as a framework.

Nov 06 '25 12:11 sean-mcmanus

@debugee Yes, the path is checked for child directories that match what we expect for a framework directory, so if you deleted a directory ending with .framework then we won't detect it as a framework.

Please look at my examples carefully. There are still many questions.

Nov 06 '25 13:11 debugee

@debugee You can run C/C++: Log Diagnostics to see if the framework paths are correctly picked up as framework paths instead of normal include paths. After switching to the pre-release channel for 1.29.0.

is includes field support test/B/b.framework ? or must add it to macFrameworkPath

Assuming that b.framework is a framework, the correct path is test/B. It can be listed in either the includePath or the macFrameworkPath.

However, in your example repository, I do not see any correct examples of frameworks. The requirement is both a ".framework" folder and a "Headers" folder beneath that. So for this example, you would need a path that looks like test/B/b.framework/Headers and the framework path is test/B. Please reference the framework documentation and take a look at "Listing 3".

Nov 06 '25 15:11 bobbrow

@debugee You can run C/C++: Log Diagnostics to see if the framework paths are correctly picked up as framework paths instead of normal include paths. After switching to the pre-release channel for 1.29.0.

is includes field support test/B/b.framework ? or must add it to macFrameworkPath

Assuming that b.framework is a framework, the correct path is test/B. It can be listed in either the includePath or the macFrameworkPath.

However, in your example repository, I do not see any correct examples of frameworks. The requirement is both a ".framework" folder and a "Headers" folder beneath that. So for this example, you would need a path that looks like test/B/b.framework/Headers and the framework path is test/B. Please reference the framework documentation and take a look at "Listing 3".

I'm just testing. I didn't compare the simulation too realistically, and it doesn't affect the reappearation of the problem. The problem still exists. You haven't fixed any errors. I just want to confirm that includePath supports incoming /Users/admin/Desktop/bug-sample/ build/dynamicFramework.framework This path's

There are a lot of errors, even the G path is lost. You have a serious mistake.

Nov 07 '25 01:11 debugee

My article is so clear.

I don't know what you are doing.

The problem has not been clarified yet.

Error repair

Nov 07 '25 01:11 debugee

Hi @debugee .

Asking Copilot to "provide an outline of the minimum required directory structure of a macOS Framework that contains headers" yielded the following (simplified) :

MyFramework.framework/
└── Headers/
    ├── <headers> i.e. Header.h

This aligns with my understanding as well. Public headers must be contained within a directory titled "Headers". In the repo you provided, there is a directory titled b.framework, but it does not contain the required "Headers" directory.

If you correct the directory structure of the framework, do you still repro an issue? If so, if you'd like to correct the contents of https://github.com/debugee/bug-sample , we'd be happy to take a look.

Note that the framework directory must be titled ending in ".framework". Also, when referring to a 'framework search path' (such as to -F or -iframework args), that is a path to a directory that contains frameworks.

For example, in the following structure:

AllMyFrameworks/
└── MyFramework.framework/
    └── Headers/
        ├── <headers> i.e. Header.h

... you would use -F<path_to>/AllMyFrameworks or -iframework<path_to>/AllMyFrameworks.

Nov 07 '25 02:11 Colengms

Hi @debugee .

Asking Copilot to "provide an outline of the minimum required directory structure of a macOS Framework that contains headers" yielded the following (simplified) :
MyFramework.framework/
└── Headers/
    ├── <headers> i.e. Header.h
This aligns with my understanding as well. Public headers must be contained within a directory titled "Headers". In the repo you provided, there is a directory titled b.framework, but it does not contain the required "Headers" directory.

If you correct the directory structure of the framework, do you still repro an issue? If so, if you'd like to correct the contents of https://github.com/[debugee/bug-sample , we'd be happy to take a look.

Note that the framework directory must be titled ending in ".framework". Also, when referring to a 'framework search path' (such as to -F or -iframework args), that is a path to a directory that contains frameworks.

For example, in the following structure:
AllMyFrameworks/
└── MyFramework.framework/
    └── Headers/
        ├── <headers> i.e. Header.h
... you would use -F<path_to>/AllMyFrameworks or -iframework<path_to>/AllMyFrameworks.

I'm not at the computer now. I guess you have scanned to judge whether there is a headers directory in it, and then treat the path as a framework. This logic is obviously wrong. For example, in this example, the build directory produces a framework, but some projects add the build directory as include, and you will treat it as a framework. Of course, this is my guess. I'm not at the computer at present.

Nov 07 '25 08:11 debugee

framework search path: /Users/admin/Desktop/bug-sample/build

Obviously, cmake-tools does not give you a suffix, but you take this as a framework, which is obtained by scanning. How to distinguish the user just as this path as include?

Nov 07 '25 08:11 debugee

Hi @debugee

Using the repo you provided, I'm unable to reproduce an issue with the framework it generates. After doing a 'configure' with CMake Tools, I see that the framework is properly detected and IntelliSense configured correctly. I still see a squiggle in sample.cpp, as it can't include the header until the header itself also exists. Once I also do a 'build' with CMake Tools, that header appears to be properly populated and the squiggle goes away.

The G path is not getting lost. It's being omitted due to no frameworks being found under that framework search path. I can improve this when a framework search path is explicit (-iframework and -F args), so it's not omitted, in case a framework is added/generated later. Though, in that scenario, I suspect it will be necessary to trigger an update (i.e. make an edit) after populating a framework there, in order for IntelliSense to re-check for existence of the header.

If you're seeing behavior other than what I described above that does not appear to be correct, could you please clarify exactly what issue you're seeing?

Nov 07 '25 22:11 Colengms

You would rather argue with me than read more of the logs and errors listed above.

I have resubmitted the bug-sample project. Please compile it by yourself.

Nov 08 '25 15:11 debugee