CLion 2016.3リリース：C11、C ++ 11およびC ++ 14のサポートの改善、CMakeプロジェクトモデルとの連携の変更など

こんにちは、Habr！ 今年はゆっくりと終わり、誰かがすでにお祝いイベントに備えており、他の誰かが考えられたすべてを完了しようとしています。 そして今、私たちは今年CおよびC ++で開発するためのクロスプラットフォームIDEの3番目のリリースをリリースしました 。 振り返ってみると（そして、新年の前夜に行うのが一般的であるように）、2016年にCLionは著しく成長し、はるかに成熟したように思われます：

• 言語サポートの観点から（さまざまなテンプレート、自動インポート、コード分析の観点からの多数の修正）、
• したがって、開発の生産性を向上させるさまざまな機能（新しいコード生成オプション、完全なステートメント、CMakeでのリファクタリング）に関して、
• 新しい言語（Python、Swift）、
• そして、もちろん、CおよびC ++での開発に関連するツール（ローカルマシン上のIDEから実行されていないプロセスのリモートデバッグおよびデバッグ、Doxygenコードドキュメント形式のサポート、バージョン管理システムとの連携における多くの改善）。

（可能な限り）ユーザーの声に耳を傾け、ユーザーの要求に集中しようとしました。 バージョン2016.3も例外ではなく、待望の多くの改善をもたらしました。

• C ++ 11に欠けていた機能に加えて、ついにC ++ 14およびC11標準の機能のサポートを開始することができました。
• CMakeプロジェクトモデルを操作するための再設計されたアプローチは、ユーザーが直面した多くの困難を解決しました（CMake生成が起動されるディレクトリを変更できないことから、パフォーマンスとメモリ消費の問題まで）。
• Windowsプラットフォームでリモートデバッグが可能になりました。
• エディターにはセマンティックハイライトがあります。
• Unreal Engineに基づいてプロジェクトのインデックスを再作成するときのパフォーマンスが向上しました。また、UE4でプロジェクトのCMakeを生成するためのサードパーティプラグインの現在の状態を調査し、それについて別の投稿を書きました 。
• 他の多くの改善と変更。

そして今、まず最初に。

C ++サポート：C ++ 11およびC ++ 14

おそらくご存知のとおり（結局、各投稿の下にあるCLionについてのコメントで私たちに尋ねます）、CLionではパーサーに依存しており、その作業は一瞬止まりません。 今回は、重要な改善点のうち、いくつか注目に値します。



1つ目は、 カスタムリテラルサポートです。 私たちはこのタスクを長い間取り上げませんでしたが、組み込み型の概念の人気の高まりとstd :: chronoおよび標準ライブラリの他の部分での使用の出現により、そのサポートが必要になりました。 コードアナライザーの誤検知エラー（カスタムリテラルのサポートの欠如が原因）とクイックドキュメントポップアップウィンドウ（Lin / WinでCtrl+Q



、macOSでF1



）を減らすことに加えて、タイプを正しく反映することに注意してください、CLionリテラルの名前を変更し、定義とそのすべての使用を更新します。







演算子について話しているので、CLionはオーバーロード演算子 （newおよびdeleteを除く）を使用する場合を探すことができることに注意する価値があります。これは、この言語機能を積極的に使用する新規および未知のコードに会うときに特に役立ちます：







このリリースで修正された組み込みコードアナライザーの複数のバグの別の原因は、 オーバーロード解決サポートの修正です。 CLionは正しい候補を正しく選択できるようになりました。つまり、未使用のコードを正しく表示したり、すべての用途を見つけたり、関数の名前を変更したり、署名を変更したりすることができます。 これに伴い、開発環境では、あいまいな呼び出しまたは呼び出しに適した関数の不足が指摘されます。CLion2016.3で適切な検査が追加されました。







一般に、私たちのチームは拡大しており、特に、コード分析により多くの人々が関与しています。 このリリースのおかげで、2016.3はこの領域に多くの変更をもたらしました。 たとえば、 sizeof（）計算に依存する分析はプラットフォームに依存するようになりました。 また、非自明なデストラクタの場合の未使用変数に関するエラー警告を修正しました（これは、いわゆる「 ガード 」イディオムにとって特に重要です）。







さらに、CLionはコードを分析するときに__attribute __（未使用）および__builtin_unreachableを理解し、正しく考慮するようになりました。 これらは、CLion 2016.3で導入された多くの静的コード分析の機能強化のほんの一部です。



言語サポートのさらなる開発における重要なステップは、区切り文字のサポートの出現と考えることができます（C ++ 14）。 将来、最新のC ++言語標準の他の可能性に時間を割けるようになることを願っています。 特定の何かに注意を向けたい場合は、 トラッカーで適切なタスクに投票することをお勧めします。

サポートC：C11

ユーザーは、CLionでの純粋なCのサポートが少し足りないことにかなり合理的に気付きました。 最終的に修正することを決定し、 gccアトミック ビルトインとキーワード_Genericのサポート 、およびキーワード_Thread_local 、 _Alignas 、 _Noreturn 、 _Static_assert 、および_Atomicのサポートを追加しました。コード：







このバージョンでは、特にCプロジェクト用のプロジェクトテンプレートを追加することを計画していたことを誰かが思い出すかもしれません。 作業は進行中であるが、まだ完了していないことを正直に認めざるを得ません。 しかし、次のアップデートのいずれかで既に2016.3.xテンプレートが表示されます。

CMake：新しいアプローチ

これらの変更の前には、多くの論争と議論がありました。 残念ながら、最初のアプローチは多くの人には向いていませんでした。 客観的な批判は、トラッカーに積極的に蓄積されていました。 たとえば、CMakeが生成されるディレクトリを変更するリクエストは、最大90票と最大90コメントを収集しました。 さまざまなカンファレンスや展示会に参加しているブログのTwitterでは、CLionが各プロジェクト（Debug、Release、RelWithDebInfo、MinSizeRel）の4つのCMake構成すべてを収集したことによるパフォーマンスの問題について繰り返し議論しました。 そして最後に、バージョン2016.3では、アプローチを大幅に作り直し、蓄積された問題の解決策を提案しました。



これで、CLionは選択された構成のみを収集します 。 この設定と、 生成を生成するディレクトリへのパスは、プロジェクト設定ダイアログの[ビルド]、[実行]、[配置]にあります。 CMake デフォルトでは、プロジェクトはcmake-build-debugという名前のプロジェクトソースコード内のディレクトリにビルドされます。 将来、ユーザーがデフォルト値を変更できるようにする予定です（たとえば、すべてのプロジェクトに共通するアセンブリのディレクトリを指定するなど）。



これらの変更により、CMakeを再度呼び出さずにCMakeが既に生成されているディレクトリからプロジェクトを開くことも可能になり、プロジェクトを開く時間を大幅に節約できます。 プロジェクトを開くには、ビルドディレクトリまたはCMakeCache.txtファイルを指定するだけです。







これは、Makefileがジェネレーターとして使用された場合にのみ機能することに注意してください。 そうしないと、CLionがCMakeを再生成します。



ご存知のとおり、CMakeは、初心者にとっては特に簡単なシステムではありません。 CMakeスクリプトのデバッグを簡素化するために、CMakeウィンドウでCMakeコマンドを呼び出したログを表示する機能を追加しました。 ただし、CMake Cacheエディターは削除されました。 代わりに、開発環境はエディターでCMakeCache.txtファイルを直接開くため、新しい値を簡単に追加できます。 将来のリリースでは、CMion Cacheファイルの「言語」をCLionに教えることで、より速く、より便利に作業できるようにする予定です。

リモートデバッグ

前回のリリースでは、GDBサーバーの下からリモートマシンで実行されているCLionアプリケーションからデバッグする機能を追加しました。 確かに、ローカルプラットフォームとリモートプラットフォームのすべての組み合わせが利用可能であったわけではありません。 2016.3のリリースにより、Windowsプラットフォームからリモートでデバッグできるようになりました。

• 別のWindowsマシンで実行され、デバッグの実行元と同じツール（MinGW / MinGW-w64 / Cygwin）でコンパイルされたアプリケーション。
  
  
  
  
• 別のWindowsマシンで実行され、デバッグが実行されるものとは異なるツールによってアセンブルされたアプリケーション（MinGWのアセンブル-Cygwinでデバッグなど）。 この場合、CLionの構成で、ローカルマシンとリモートマシンのパスの正しい対応を指定する必要があります。
  
  
  
  
• Linuxマシンで実行されるアプリケーション。 ここでは、クロスプラットフォームのGDBデバッガーが必要です（つまり、CLionの標準のGDBデバッガーは機能しません）。 ブログでそれを組み立てる方法について読むことができます。 もちろん、デバッグシンボルとローカルマシンとリモートマシンのパスの対応を使用してファイルへのパスを示す、適切に構成された構成が必要になります。

ところで、リモートデバッグに加えて、デバッガで多くの修正が行われました。 そのため、たとえば、CLionはPYTHONPATH環境変数を上書きしなくなりました。これにより、特にPythonのC拡張機能（Python C拡張モジュール）をデバッグできます。

セマンティックハイライトなど

別の待望の機能は、セマンティックハイライトです！ すぐに有効にする方法を説明します：エディターに移動します| 色とフォント| 言語のデフォルト、セマンティック強調表示グループを見つけ、 各パラメーターとローカル変数の一意の色のチェックボックスをオンにします。 さらに、自由裁量で色の範囲を調整したり、デフォルト値を使用したりできます。



セマンティックハイライトは、プログラムの実行中にデータフローがどのように変化するかをよりよく理解できるように設計されています。 これを行うには、すべての変数とパラメーターを（可能であれば）異なる色でペイントします。



CLionでの動作：

• 各ローカル変数とパラメーターには、独自の色が割り当てられます。
• 関数またはラムダ本体の内部で、CLionは色の繰り返しを避けようとします。
• 同じ名前の識別子は同じ色になります。

まあ、それは次のようになります：







コードの強調表示に関連するもう1つの変更点は、構成を変更するときにエディターで解決コンテキストが自動的に切り替わることです。 なぜこれが必要なのか見てみましょう。



ソースファイルが2つの異なるCMakeターゲットのアセンブリに含まれている状況を想像してください。 同時に、これらのターゲットの設定は異なり、コード自体には、これらの設定に応じて条件付きコンパイルのブロックがあります。 この状況でのコードエディターはどうですか？ コードのこれらの部分を正しく強調表示する方法、使用事例を探す方法、正しいコードのリファクタリングを行う方法は？ 答えは簡単です。単一のターゲットの設定を選択して使用します。 しかし、どれですか？ あなたが現在取り組んでおり、特定の時間にあなたが収集/デバッグしているものは私たちにとって論理的なようです。 したがって、実行/デバッグ構成を切り替えると、CLion 2016.3はファイルの解決コンテキストを自動的に切り替えます。







それでもなお、これが望んでいない場合は、エディターの右下隅にあるresolve-contextの手動切り替えを使用してください。 この場合の自動切り替えは、IDEを次に再起動するまで無効になります（ただし、これは機能ではなくバグです）。

アンリアルエンジン

Habréでは、CLionでUnreal Engineを使用したゲーム開発についての議論がすでにありました。 このリリースの一環として、この場合にユーザーをどのように支援できるかを確認することにしました。 そしてその理由は、Unreal Engine用のサードパーティプラグインの出現でした。これにより、CLionでプロジェクトを開き、必要なCMakeスクリプトを生成できます。 このプラグインを試してみましたが、ゲームエンジンのすべてのソースコードが含まれているわけではなく、必要な部分だけが含まれているため、結果のCMakeによってCLionがプロジェクトのインデックスをより高速に作成できることに驚きました。



喜んで、CLionで既にインデックス化されたプロジェクトを再び開く時間を大幅に短縮しました 。 また、同僚が反射指定子の自動補完用のプラグインを追加しました。







CLionのUnreal Engineに基づいたゲームの開発方法に関する詳細な投稿は、ブログにあります。

その他の変更

CLion 2016.3のリリースには他にも多くの変更と修正がありますが、遅れないように、簡単に言及します。

• Doxygen形式のドキュメントテンプレートを生成すると、C ++テンプレートを使用して、関数、構造、およびクラスのテンプレートパラメーターのtparamタグを生成できるようになりました。
  
  
  
  
  
  
  
  
• [パスで検索]ダイアログでは、このアクションが呼び出されるパスに関係なく、検索設定（選択したスコープ、ファイル名によるフィルターなど）が保存されるようになりました。
  
  
  
  
• IntelliJプラットフォーム全体とともに、CLion 2016.3リリースには、 サインオフコミット、まだプッシュと呼ばれていないアクションをロールバックする機能、削除されたローカルブランチを復元する機能、Git / Mercurialログの検索パフォーマンスの改善など、バージョン管理システムのサポートの改善が含まれています別の。
  
  
  
  
• また、macOS Sierraユーザーの場合、このリリースにはエディターでのスクロールの重要な修正と、暗い（Darcula）および明るい（デフォルト）テーマの両方でデフォルトで使用されるSan Franciscoフォント（SF NS Text）が含まれています。

以下は、開発弁護士のPhil Nashによる英語の短いデモです。







通常、興味があり、新しいバージョンを試してみたい場合は、通常どおり30日間の無料試用版があり、価格セクションでサブスクリプションのコストを確認できます。



英語のブログの記事と更新をお楽しみに。 コメントでご質問にお答えします。



JetBrains CLionチーム

開発への意欲