References and Call Hierarchy are wrong for constructors
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- cpp, typescript
- Domain
- devtools
Research direction
Extract P1-ctor-Widget-int.zip and reproduce the queries from src/widget.h against the construction sites in main.cpp and the definition in widget.cpp. Compare textDocument/references and callHierarchy/incomingCalls with the documented expected counts. Done means the constructor returns only its declaration, definition, and two construction sites, and both incoming callers appear.
Written by the indexing model from the issue text.
Description
Environment
cpptools — References and Call Hierarchy are wrong for the constructor ui::Widget::Widget(int)
| Field | Value |
|---|---|
| Symbol (spec id) | ctor-Widget-int |
| Declaration | explicit Widget(int id); |
| Query position | src/widget.h:13:14 (cursor on Widget) |
| Affected LSP requests | textDocument/references, callHierarchy/incomingCalls |
| Repro archive | P1-P1-ctor-Widget-int.zip (this folder) |
Summary
Two independent defects hit the same constructor when it is queried in VS Code with the C/C++ extension (cpptools):
- Find All References returns every mention of the
Widgettype instead of the actual construction sites (over-count). - Show Call Hierarchy → Show Incoming Calls returns nothing, so the constructor looks like it is never called (false "no callers").
The correct (expected) results are shown below.
Environment
- Editor: Visual Studio Code 1.33.5
- Extension: C/C++ (
ms-vscode.cpptools), default IntelliSense engine - Language standard: C++20 — the fixture is freestanding (no STL/toolchain needed to parse)
Steps to reproduce
- Extract
P1-P1-ctor-Widget-int.zipand open thecpp-projectfolder in VS Code with the C/C++ extension enabled. - Optionally configure with CMake Tools (preset
cdb) so cpptools picks upcompile_commands.json; the freestanding fixture also parses under default C++20 IntelliSense. - Open
src/widget.h, place the cursor onWidgetinexplicit Widget(int id);(line 13, col 14).
Adding a full repro in P1-ctor-Widget-int.zip attached file.
P1-ctor-Widget-int.zip
Defect 1 — textDocument/references
- Invoke Find All References (
Shift+Alt+F12).
| Source | Result count |
|---|---|
| Expected | 4 |
| VS Code / cpptools | 28 |
Expected (4): the declaration (widget.h:13), the out-of-line definition (widget.cpp:9, Widget::Widget(int id)), and the two Widget(int) construction sites in main.cpp — the static ui::Widget storage(42); initializer in allocWidget() and ui::Widget b(7); in main().
Actual (28): every occurrence of the ui::Widget type — the typedef, the g_current pointer, the takeWidget/makeDefault/allocWidget/asConst parameter and return types, the Serializer<ui::Widget> specialization, and the type-mention lines in widget.cpp — none of which construct an object. A references query on the constructor collapses to "every mention of the enclosing type."
Defect 2 — callHierarchy/incomingCalls
- With the cursor at the same position, invoke Show Call Hierarchy and expand Incoming Calls.
| Source | Result count |
|---|---|
| Expected | 2 |
| VS Code / cpptools | 0 |
Expected (2): incoming calls from allocWidget() (the storage(42) construction at main.cpp:29) and from main() (the b(7) construction at main.cpp:55).
Actual (0): the Call Hierarchy view shows no callers, i.e. the constructor appears to be dead.
Why it matters
- The empty incoming-calls result is a false "no callers" on live code: an automated agent (or a developer) can conclude
Widget(int)is never used and delete/prune construction paths that are actually exercised. - The reference over-count means "where is this object constructed?" cannot be answered, the list is dominated by unrelated type mentions.
- Dominant language
- TypeScript
- Stars
- 6.2k
- Forks
- 1.7k
- Avg merge
- 14h 46m
- Merged PRs (30d)
- 61
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/vscode-cpptools
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
microsoft/vscode-cpptools#14787 ·
-
[Bug] cpptools fails to start on Ubuntu ARM64 due to missing execute permissions on shared libraries Openbug fixed Language Service regression
microsoft/vscode-cpptools#14779 · 1 assignee ·
-
Language Service more info needed
microsoft/vscode-cpptools#14778 · 1 comment · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 64/100
microsoft/vscode-cpptools#14769 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
microsoft/vscode-cpptools#14768 · 1 comment ·
All issues in microsoft/vscode-cpptools
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
danielmiessler/LifeOS#2218 ·