VS2010のsquiggleについて

Visual C++ Team Blog : C++ Gets Squiggles!

Visual Studio 2010のインテリセンスは、コンパイラレベルのsyntax上、及びsemantic上のエラーを、コードを編集している際にすら、表示できる。

エラーは、波打った下線として、その箇所に表示される。これをsquiggleと呼ぶ。squiggleの上にマウスカーソルを合わせると、エラーメッセージが表示される。また、エラーリストウインドウにも、表示される。squiggleは、編集中のコードのエラーを見るのに都合が良く、エラーリストウインドウは、現在の translation unit のエラーを見るのに最適である。これらはすべて、ビルドせずに見ることができる。

機能の設計

この機能を設計するにあたって、ふたつの事を考慮した。ひとつは、当然ながらプロダクティビティである。ビルドを待たずにエラーを直せるのは、実に便利で、時間の節約になる。また、インテリセンスが動かないという問題にも対処したかった。というのも、インテリセンスとは、ユーザーからしてみればブラックボックスなのだ。大抵うまく動いてくれる。しかし、動かない時、その問題が分からないと言うことだ。インテリセンスはその問題を表示できるようになったので、ユーザーはエラーを直すか、プロジェクトの設定項目を見直すかできる。

この機能を設計するにあたって、ひとつ決めなければならないことがあった。どのくらいの頻度で、編集中のコードのエラー表示を更新するかと言うことだ。仮に頻度が低ければ、大量のエラーで埋もれてしまい、悲惨なことになる。しかし、高頻度で更新を行えば、やはりそれも、悲惨なことになる。たとえば、、"vector"と入力している最中に、"vect"という部分にsquiggleを表示してしまうだろう。それに、バックグラウンドのパースにかまけて、CPUを浪費したくはない。

いいバランスとは、編集後やスクロール後のアイドル時に一秒間待つというものだという結論に達した。「アイドル」とは、キーをタイプせず、別の場所にスクロールもしない状態のことだ。

また、編集後に作られた新しいエラーと、既存のエラーをどうするかという問題に関して、いくつかの設計を試みた。例えば、ひとつの設計として、編集後は、すべてのsquiggleを、即座に消去して、新しいエラーが判明次第、再描画するというものがあった。また、この派生版として、編集しているコードの箇所から、下部のエラーだけ消去するという設計も試みた。（およそ、編集後のコードが及ぼす影響としては、まずそのコードから下であろうし）。この設計は、古いエラーを見ずに済むという利点があった。しかし、ユーザビリティのテストで、いらつく頻繁なちらつきが起こることが分かった。さらに、エラーが消えたのが、修正されたのか、それともアップデート中だから消えたのかということが分かりづらいという欠点もあった。採用された設計は、既存のsquiggleは、編集後もそのまま残しておき、新しいエラーが判明したら、差し替えるという手法になった。アップデートは非常に早いので、この方法はうまくいった。

技術的な問題

この機能の技術的な問題としては、高速でなければならないということだ。ご存じのように、巨大なC++のプロジェクトをビルドするには、何時間もかかる。この問題を解決するために、ひとつの translation unit のみに注目するという方法がとられた。translation unit とは、ひとつの .cppファイルと、そのファイルがinclude するヘッダー群である。しかしそれでも、squiggleのようなリアルタイム・コンパイルを実現するためには、遅すぎた。

パフォーマンスを上げるため、インクリメンタルなパース技法を用いて、パースするコードを最小に抑えるようにした。これによって、実際のビルドにかかる時間より、すばやくコードをパースできる。実際、ひとつの.cppファイルをコンパイルするよりも早くパースできる。アイディアとしては簡単だ。しかし、C++のような、context-sensitiveな言語で行うのは、じつに厄介だった。

ファイルを開くと、global symbol tableを構築するのに必要なだけのコードをパースし、local symbolしか付け加えることのない、多くのコードはスキップする（例えば､関数内のコードだとか）。symbol tableを構築したならば、スキップしたコードを、オンデマンドでlazilyにパースする。例えば、関数内は、実際に画面上で見た時にしかパースしない。もし、ある関数内のコードを変更したならば、その関数ひとつだけ再パースできる。もちろん、すでに言及したように、これらはすべて、アイドル時に行われる。このパースの技法は、高速で役立つエラーメッセージを、巨大で複雑なコードベースを編集していても提供できるだろう。

External build systemsは省略。原文を参照されたし。

この機能を実装するのは楽しい事であった。特に、ドッグフードを食す（訳注：自社製品を実際に自分で使うという意味のMS社内用語）のは格別だった。わざわざ毎回ビルドしなくてもいいというのは実にすばらしい。Beta 1で、この機能を試せる。

十年前のコンピューターには、ここまでの処理能力はなかった。それを考えると、数十年後は、ビルドなんて意識しないプログラミング環境になっているだろうか。アイドル時に常にフルビルドを試みても、全く差し支えないほどの処理能力になっていれば、できるはずだ。