microsoft / microsoft/vscode-cpptools

Locals/Watch view: Alternative Rendering for Empty Containers

オープン
#12,435 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

debugger Feature Request help wanted
主要言語
TypeScript
スター
6.2k
フォーク
1.7k
平均マージ
14時間 46分
マージ済み PR(30日)
61

説明

Feature Request

When debugging in C++, multiple different types of variables display as "{...}", under cetrtain conditions, in the locals/watches views:

image
Objects on the stack are rendered this way when the pretty-printer is still loading, e.g. after just hitting a breakpoint. So are empty containers, and also empty optionals. Here, painter is an object whilst multiChannelAndStatuses is an empty container, and plotsEnabled is a non-empty container. I can't easily discern this by looking at them. It's hard to scan what are objects, what are containers or C-style arrays, what are other values with special handling.
image
Added to this that it's possible within the language to have invalid pointers, junk on the stack and values not yet initialised, it can become even harder to keep track easily of what's going on.

So I find this confuses my debugging, especially in the context of children that are lazily expanded, and especially when VS Code doesn't display the type of each object next to its name and value, as some other IDEs do. I keep having to expand children to verify if they really are empty, if they haven't loaded yet, or if I'm not sure if something is a container-like type or really an object that's not yet been expanded. This slows me down and makes me more likely to lose track of my train of thought for a second.

I'd prefer to see more specific rendering for the different symbols based on their types. I assume this is within the C++ extension, or between it and VS Code itself, since the debugger's pretty-printers must be working in order for me to expand the elements etc., and when using other languages, I get much more detailed information printed alongside the variable's name.

It would make more sense to me to use special values for some of these situations - for a container I'd rather see a brief summary of how many items are within, like [5 items], Sprocket - [5] or even just [5], and at least something like [] or {empty} for empty containers. Similarly, I think empty optionals could be rendered to show nullopt, empty, or {}, demarcating them from an unexpanded object. I find the experience in Qt Creator here, where the type is often listed in another column, and unexpanded objects may be previewed simply as the type name when there isn't a meaningful representation of their value. I think it also highlights invalid addresses and unitialised values in red, making it easy to search for lifecycle issues and null pointers nested deeply within some hierarchy.

All in all, I'm pretty open to what formats might be chosen, but, the main thins is that I don't think it makes sense to render all these different cases as the same {...} preview, as this then makes it harder to scan through the values, and it's not really adding anything to the window. Any kind of differentiation I think would help.

Thanks

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

ファイル、テスト、エントリポイントは特定されていません。まず、示されている C++ の locals/watches のケース(オブジェクトの読み込み、空のコンテナ、空の optional)を再現し、レンダリングを C++ 拡張機能と VS Code のどちらが担当すべきかを判断してください。完了の条件は、子要素を展開しなくても対象の値を見た目で区別でき、報告されたケースについて合意した表現が定められていることです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
cpp, typescript
領域
devtools
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。