OpenKal grants omit MSVC headers when Visual Studio is installed outside Program Files
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 70/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- devtools
Hướng nghiên cứu
Start with src/engine/clangd/grants.cpp and its grant interface in src/engine/clangd/grants.cppm; trace how toolchain root arguments and include paths become grants. Then inspect existing grant tests and add coverage for an MSVC installation outside Program Files, including separate and joined root arguments. Done means derived grants cover the MSVC header directory and the regression test passes.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Version
Extension and server: 0.0.20. Bundled clangd: 23.1.0-mcppls.9.
The diagnostic bundle identifies the payload as a from-source build of 8923698cde330586bca99534dedea012d161dcf7 with dirty: true, built on 2026-11-06. The analysis below uses that commit's source.
Editor
Visual Studio Code 1.145.2, Windows x64.
Operating system
Windows, build 10.0.26300.9711.
Build system
mcpp; the captured project model reports producer version 2026.10.31.3, LLVM 23.1.3, target x86_64-pc-windows-msvc, MSVC STL 14.51.36231 and Windows SDK 10.0.26100.0.
What happened
Opening an mcpp C++ modules project produces missing MSVC runtime/STL header diagnostics even though those files exist and the toolchain paths are correctly identified. Visual Studio is installed outside Program Files, at D:/VisualStudio2026.
The first relevant failure in the captured session is:
2026-11-08T09:35:07.182Z
clangd could not scan D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/modules/std.ixx
for its modules: fatal error: 'vcruntime.h' file not found
Other scans fail with 'excpt.h' file not found, 'type_traits' file not found, etc. std and other modules then get stand-ins; subsequent errors include use of undeclared identifier 'std'. The final plan has 148 issues, 18 left-out units and 19 stand-ins. Resetting the workspace cache during this session did not resolve the problem.
What you expected
clangd should be able to read headers belonging to the selected MSVC toolchain regardless of where Visual Studio was installed. A correctly detected toolchain should not require a manual directory grant.
Evidence and likely cause
The compile command explicitly contains:
-Xmicrosoft-visualc-tools-root D:\VisualStudio2026\VC\Tools\MSVC\14.51.36231
-Xmicrosoft-windows-sdk-root C:\Program Files (x86)\Windows Kits\10
-Xmicrosoft-windows-sdk-version 10.0.26100.0
--target=x86_64-pc-windows-msvc
However, the engine-start event's grants contains only this part of the MSVC installation:
{
"path": "D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/modules",
"unchanging": false,
"writable": false
}
Neither D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/include nor an ancestor covering it appears in the grant list. Default system grants include C:/Program Files, C:/Program Files (x86) and C:/ProgramData, which cover the Windows SDK but not this Visual Studio installation. engine.confine is already false; the explicit OpenKal directory grants are still supplied.
In grants.cpp at the payload commit, PATH_FLAGS handles -I, -isystem, -imsvc, etc., but not -Xmicrosoft-visualc-tools-root or -Xmicrosoft-windows-sdk-root. system_roots() uses the Program Files/ProgramData environment variables. Thus, the MSVC modules directory is collected from its source path, while the sibling header directory is missed.
The grant interface documentation explains that an engine given explicit grants can only access those directories. This appears to be an mcppls grant-derivation defect, rather than a missing header installation or a clangd parser defect.
Independent checks
All three files exist:
D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/include/vcruntime.h
D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/include/excpt.h
D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/include/type_traits
With the same explicit MSVC/SDK flags, the native LLVM 23.1.3 compiler successfully checks:
#include <vcruntime.h>
#include <excpt.h>
#include <type_traits>
static_assert(std::is_same_v<int, int>);
Running the installed clangd.okb directly through okrun.exe --check=..., without mcppls's explicit grant list, also reports All checks completed, 0 errors. A small module/importer probe using the same toolchain flags passes too. These checks establish that the files are readable and the bundled engine can handle them when launched independently; they are not a constrained-grant regression test.
Steps to reproduce
- Install Visual Studio/MSVC outside the default Program Files roots, for example under
D:/VisualStudio2026. - Open an mcpp modules project whose compile commands select it using
-Xmicrosoft-visualc-tools-rootand import itsstdmodule. - Use the OpenKal engine payload with default
mcppls.grants: []. - Inspect the engine's derived grants and module-scanning diagnostics: the MSVC
modulesdirectory is accessible, but its siblingincludedirectory is missing from the grant coverage.
Suggested fix / workaround
Derive grants from the selected toolchain roots as well as include flags, covering the MSVC headers and supporting SDK/toolchain-root arguments with separate or joined values. A regression test should place MSVC outside the default system roots and verify that the derived grants cover its header directory.
A possible temporary workaround is:
"mcppls.grants": [
"D:/VisualStudio2026/VC/Tools/MSVC"
]
Then restart the language server. This workaround has not yet been verified in the editor.
Diagnostic bundle
- I attached the diagnostic bundle
The local bundle is mcppls-bundle-20261108T094157.162Z.zip; relevant excerpts are included above. The full ZIP is not attached to this issue.
The same session also records failed mcpp model refreshes with previous compiler unit is occupied or unknown, after which mcppls retains the cached model. That is a separate observation; this report concerns the header-directory grant omission, which is visible before those refresh failures.
- Ngôn ngữ chính
- C++
- Star
- 25
- Fork
- 2
- Merge trung bình
- 21 giờ 5 phút
- Pull request đã merge (30 ngày)
- 13
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Sunrisepeak/mcpp-language-server
-
Extraneous quote in include completionCó thể đã có người làm @Sunrisepeak đã nhận 1 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Sunrisepeak/mcpp-language-server#80 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Sunrisepeak/mcpp-language-server#66 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 1/100
Sunrisepeak/mcpp-language-server#77 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Sunrisepeak/mcpp-language-server#71 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
Sunrisepeak/mcpp-language-server#59 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của Sunrisepeak/mcpp-language-server
Issue tương tự
-
go perft exits when EvalFile is unavailableCó thể đã có người làm @Muawiya-contact đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
official-stockfish/Stockfish#7292 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
arvidn/libtorrent#9149 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Niko1221/Strata#5560 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
hyprwm/xdg-desktop-portal-hyprland#453 · 1 bình luận ·