Movatterモバイル変換

Compiler Platformコード解析とC#の未来C# とともに祝15周年岩永信之

今日話すこと• 2015世代でC#チームが提供するもの• C# 6.0• .NET Compiler Platform• それがもたらす影響• 独自のアナイライザー作成• Code-Aware Library• 課題• C# 7.0以降にどうつながるか

C# 6.0.NET Compiler Platform.NETチーム、C#チームが提供する“現状”

C# 6.0• 自動プロパティの改善• expression-bodied関数メンバー• 文字列補間• nameof演算子• null条件演算子• using static• 例外フィルター• catch/finally句内でのawait 等々正直なところ華はない• 機能追加よりも優先すべきことがあった• 限られた時間の中で“2015”に間に合うもの

C# 6.0• 自動プロパティの改善• expression-bodied関数メンバー• 文字列補間• nameof演算子• null条件演算子• using static• 例外フィルター• catch/finally句内でのawait 等々正直なところ華はない• 機能追加よりも優先すべきことがあった• 限られた時間の中で“2015”に間に合うものC# 6.0の話は今日はほぼしません既存資料※をご覧ください※ http://ufcpp.net/study/csharp/ap_ver6.htmlhttp://www.slideshare.net/ufcpp/csharp6IDE前提の機能 .NET Compiler Platform

IDE前提の機能• nameof演算子• 識別子名を文字列として取得できる機能• 識別子でないものはnameofの中に書けない• 修正漏れとかをコンパイルエラーにできる• IDEの中で真価を発揮• 修正漏れがあればリアルタイムに気付ける• リファクタリングの対象になる• 識別子のリネームに追従するnameof(x) == "x" コンパイルするだけならほぼただの文字列リテラル

Demohttps://github.com/ufcpp/UfcppSample/tree/master/Demo/2015/CompilerPlatform/NameofDemo

プログラミング言語のIDE連携• C# = IDEの恩恵を強く受けれる言語• (今までも)リアルタイム解析常にバックグラウンドで解析走ってる• 「ビルド」操作した時のコンパイル時間短い• コンパイル時よりももっと早い段階で、常にどこに問題があるかわかる• (今、さらに)nameof演算子でこの傾向が強まる"x" : 文字列の中の意味をコンパイラーは知らない実行してみて初めて問題がわかるnameof(x) : ()の中の意味をコンパイラーが知ってるリアルタイム解析の対象

.NET Compiler Platform• C#コンパイラーを1から作り直した• コードネーム“Roslyn”、製品名“.NET Compiler Platform”• 単なるコンパイラーではなく、プラットフォーム化旧source executable新source executableブラックボックス出力しか取れないホワイトボックス化中間データを取れるように• 抽象構文木の取得・書き換え• 拡張性の提供誰でもIDEと連携できる

プラットフォーム化が最優先• C# 6.0(機能追加) < 作り直し(プラットフォーム化)• 作り直しで手いっぱいで大きいことまでできない• (作り直して保守が楽になったからこそ細かいことができる)• C# 6.0• 悪く言えば、おまけ、華がない• 良く言えば、そんな大変な中よく新機能を2015に間に合わせた実はおまけ

Compiler Platform誰でもコンパイラーの中身に触れられる誰でもIDE連携できるまず、「作る側」の話

コード解析(Visual Studio標準)コンパイルはできるんだけど、人的ミスっぽいものを警告アイテムテンプレートには多めに出しておいて、最後に整理して消す人それぞれで流儀が違うけど、プロジェクト内ではそろえたい

コード解析(Visual Studio標準)緑の下線(警告):可能な限り直すべきもの半透明(情報):問題はないけども、直しようがあるものusing System

コード解析(Visual Studio標準)• クイックアクション直しようがあるものには直し方も提示、自動修正電球マークが目印)一斉修正ドキュメント内全部プロジェクト内全部ソリューション内全部(

プラットフォーム化• こういうコード解析を誰でも作れるように• 作れるもの:• アナライザー(analyzer)• シンボル追加、メソッド追加、コンパイル時などのタイミングで• コードを解析して、エラー/警告/情報を出す• コード修正(code fix)• 特定のエラー/警告/情報に反応して• 修正方法を提示して• その場限り、ファイル内全部、プロジェクト内全部、ソリューション内全部などをまとめて修正

コード解析の自作に必要なもの(1)• Visual Studio 2015 SDK• 「Visual Studio SDK」とかで検索、ダウンロードhttps://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs.aspx

コード解析の自作に必要なもの(2)• .NET Compiler Platform SDK Template• 「拡張機能と更新プログラム」で「.NET Compiler」とかで検索

コード解析の自作• テンプレート → Extensibility → Analyzer with Code Fix

デモコード解析本体テストVisual Studio拡張(NuGetパッケージが作られる)(F5実行でVisual Studioをデバッグ起動)テンプレ通りの状態でアナライザーとコード修正が1つずつ

配布• VSIX (Visual Studio Extension※)形式• Visual Studioにインストール• 全プロジェクトから使う• Visual Studio Galleryで検索・ダウンロード可能†• NuGet形式• プロジェクト単位で参照• 使う・使わないをプロジェクトごとに切り替え• ライブラリと同梱で配布可能• NuGet Galleryで検索・ダウンロード可能†※ VSI (Visual Studio Installer)の流れを組んでるからVSIXと言うみたいファイル構造的には必要なファイルをZIPで固めただけ† もちろん、VSIX/NuGetパッケージをファイル配布してもOK

配布: Visual Studio GalleryWebサイト Visual Studio上から検索

配布: NuGet GalleryWebサイト Visual Studio上から検索

拡張である意味• Visual Studio/C#コンパイラー標準でない意味• 特定分野の限定機能も提供できる ⇔ 汎用• 実装方法をカスタマイズできる ⇔ 汎用性と利便性は両立しにくい• 時代遅れになったら辞めればいい ⇔ 足すより減らす方が難しい• 経験則的な機能※も提供できる ⇔ 確実な機能しか提供できない• 嫌なら使わなければいい ⇔ 嫌でも使わされる• ライブラリ固有事情を汲める ⇔ ライブラリのことは知らないコンパイラーは…拡張なら…※ 端的にいうと誤判定・判定漏れもあり得る

拡張である意味• Visual Studio/C#コンパイラー標準でない意味• 特定分野の限定機能も提供できる ⇔ 汎用• 実装方法をカスタマイズできる ⇔ 汎用性と利便性は両立しにくい• 時代遅れになったら辞めればいい ⇔ 足すより減らす方が難しい• 経験則的な機能※も提供できる ⇔ 確実な機能しか提供できない• 嫌なら使わなければいい ⇔ 嫌でも使わされる• ライブラリ固有事情を汲める ⇔ ライブラリのことは知らないコンパイラーは…拡張なら…※ 端的にいうと誤判定・判定漏れもあり得るCode-AwareライブラリCode-Aware:(ライブラリ利用側の)「コードまで理解する」「コードを意識した」• ライブラリ固有の事情にそったアナライザーを• ライブラリ本体と同梱して配布

プラットフォーム化の可能性「作る側」になる人は多くない一般開発者への恩恵は何か「使う側」の話

作る人 <<[壁]<< 使う人• 「誰でも作れる」≠「誰もが作る」• 実際とのところ、作る人は少数• だいたい、作るの結構大変• 一度作ったらしばらく手を入れずに使い続けれる• 誰かが作って、みんなが使う• プラットフォームには上モノが乗って初めて価値が出る• 「PCはアプリがなければただの箱」と同じ理屈作りやすくなる → 作られる → 使う人が便利にここまで揃って初めて「目玉機能」になる

いくつか紹介• 「ただの箱」でないところを紹介• 現時点での話• まだまだスタート地点に立ったばかり• CTPまでは変更が多くて追いにくかったし、RCが出てまだ1・2ヶ月• たまに、Galleryを検索してみるといいと思う• おおまかに分類• コード解析系• Code-Awareライブラリ系• メタプログラミング系

いくつか紹介What 何をしてくれるものかWhy どうしてC#コンパイラー/VSの標準機能にならないのかどうしてライブラリ＋アナライザーなのかOwner 拡張ツールの作者(中心人物、会社、チーム)

コード解析系• 単純に静的コード解析＋リファクタリング

C# EssentialsWhat C# 5.0を6.0化するのをガイドしてくれる主に ?. と =>Why C# 5.0→6.0の移行期にしか要らない古い形式のままで使いたい人もいるOwner Dustin Campbell(C#/VBチームのプログラムマネジャー)https://github.com/DustinCampbell/CSharpEssentials

StyleCop AnalyzerWhat StyleCopが提供していたコード解析機能をVS拡張にWhy 趣味を選ぶ(人によって流儀が違う)指示が細かすぎるOwner Sam HarwellCoverity (静的解析ツールベンダー)社員、MS MVPhttps://github.com/DotNetAnalyzers/StyleCopAnalyzers

NRefactory 6What NRefactory (SharpDevelopのコード解析)がRoslyn実装に(MonoDevelopのコード解析もNRefactory)Why SharpDevelopチームが主導VS標準よりも細かい指示多めOwner SharpDevelopチームhttps://visualstudiogallery.msdn.microsoft.com/68c1575b-e0bf-420d-a94b-1b0f4bcdcbcc

Code CrackerWhat コミュニティベースでいくつかの便利機能を実装var強制、Regexの静的解析などWhy コミュニティを中心に開発趣味を選ぶOwner 数名のMS MVPhttps://github.com/code-cracker/code-cracker

Code-Awareライブラリ系• ライブラリ固有事情を汲み取り• そのライブラリ以外にとっては役に立たないコード解析• 現状、あんまりいいのが見つからなかったので自作のを紹介

(デモ用) FluentArithmeticWhat デモ用に、最低限の機能に絞ったCode-Awareライブラリ1.Add(2).Mul(3)みたいな書き方で整数四則演算Why .Dive(0)を認めないとか1.Add(2)を3に修正したりとかこのライブラリ以外でまったく役に立たないOwner 自作https://github.com/ufcpp/UfcppSample/tree/master/Chapters/DevEnv/CodeAwareLibrarySample

(デモ用) FluentArithmeticWhat デモ用に、最低限の機能に絞ったCode-Awareライブラリ1.Add(2).Mul(3)みたいな書き方で整数四則演算Why .Dive(0)を認めないとか1.Add(2)を3に修正したりとかこのライブラリ以外でまったく役に立たないOwner 自作https://github.com/ufcpp/UfcppSample/tree/master/Chapters/DevEnv/CodeAwareLibrarySample0割りエラーリテラル同士の演算を短縮

LazyMixinWhat 構造体を他の型に埋め込んで使うhas-aな実装で、is-a的な体験を提供Why ライブラリだけで縛れない規約が多すぎるダメな書き方をエラーに、推奨の書き方をコード生成Owner 自作https://github.com/ufcpp/LazyMixinもっと汎用的な仕組みに書き換え中: https://github.com/ufcpp/MixinGenerator

LazyMixinWhat 構造体を他の型に埋め込んで使うhas-aな実装で、is-a的な体験を提供Why ライブラリだけで縛れない規約が多すぎるダメな書き方をエラーに、推奨の書き方をコード生成Owner 自作https://github.com/ufcpp/LazyMixinもっと汎用的な仕組みに書き換え中: https://github.com/ufcpp/MixinGeneratorreadonlyがついていると意図しない動作になるのでエラーにする推奨の使い方をコード生成

他にこんな使い方できそう• JSONライブラリで、文字列リテラル中のJSON解析を同梱• LINQ Providerに「使える式は何」警告機能を付ける。

メタプログラミング系• コード修正というより、コード生成• アナライザー実装にすることで• コード生成元もC# ⇔ T4テンプレート: 元がキモイ• コード生成結果が見える ⇔ PostSharpなど: 生成結果が見えない• 現状、あんまりいいのが見つからなかったので自作等を紹介わかりやすさ大事。特に、継続的に保守する場合見えないとデバッグが大変。何が原因か追えない

NotifyPropertyChangedGeneratorWhat INotifyPropertyChanged実装をコード生成Why 特定用途すぎるし、実装方法にバリエーションがある手書きがむちゃくちゃ大変Owner neuecc (MS MVP)https://github.com/neuecc/NotifyPropertyChangedGenerator

RecordConstructorGeneratorWhat immutableな型のコンストラクターを書くのだるいのでコード生成するようにしたWhy C#ができた当初(15年前)には考慮に欠けてたC# 7.0で状況改善しそうだけども、それまでのつなぎにOwner 自作https://github.com/ufcpp/RecordConstructorGenerator

将来の話まだまだ始まったばかりで課題だらけこれから充実させていってほしいものもあるC# 7.0

IDE連携 ≠ Visual Studio連携• Q. で、Visual Studio以外で使えるの？• A. Roslynオープンソース化の意味がここで強く効いてくる• 現状、Visual Studioのみだけど• Xamarin Studio : 対応中みたい• OmniSharp : Roslyn化フォークがある、作業中• ATOM, Emacs, Sublime Text, Vim, ...• Visual Studio Code : ATOM実装(コード解析はOmniSharp任せ)

難易度: 「可能にはなった」程度• コンパイラーの中身に触れるようになっただけvar props = propertyNames.Select(p => new Property(p)).ToArray();var docComment = GenerateDocComment(props.Select(p => p.Name));var parameterList = ParameterList().AddParameters(props.Select(p => p.ToParameter()).ToArrvar body = Block().AddStatements(props.Select(p => p.ToAssignment()).ToArray());return ConstructorDeclaration(typeName).WithModifiers(SyntaxTokenList.Create(PublicToken)).WithParameterList(parameterList).WithLeadingTrivia(docComment).WithBody(body).WithAdditionalAnnotations(Formatter.Annotation);• 読めた代物じゃない• 書くのも大変/// <summary>Record Constructor</summary>/// <param name="name"><see cref="Name"/></param>/// <param name="x"><see cref="X"/></param>/// <param name="y"><see cref="Y"/></param>public Point(string name = default(string), int x = default(int), int y = default(int)){Name = name;X = x;Y = y;}

解析用の新構文が欲しい• 型のパターンマッチング構文が欲しい• C# 7.0で入りそう(確度高め)• ぶっちゃけ、“内需”だと思うvar id = statement.Left as IdentifierNameSyntax;if (id == null) continue;if (id.Identifier.Text == p.Name)return;特定の型の場合だけ処理アナライザーを書いているとこういうコードだらけにif (statement.Left is IdentifierNameSyntax id&& id.Identifier.Text == p.Name)return;C# 7.0 提案パターンマッチis演算子の拡張

構文欲しい修正用式ツリー• 組み換え可能な、Roslyn版式ツリーが求められる• 要望としては出ているものの、構文の具体案なしAssignmentExpression(SyntaxKind.SimpleAssignmentExpression,IdentifierName(Name.Upper),IdentifierName(Name.Lower))); 「X = x」みたいなものを作るだけでこの大変さ`${Name.Upper} = ${Name.Lower};`こういう類のメタプログラミング構文が欲しい(この構文は適当)

参照がめんどくさい• 普通のライブラリの参照方法• アナライザーの参照ファイルを参照プロジェクトを参照NuGetパッケージを参照※※ NuGet参照するには、NuGetのstartupスクリプトに参照設定を書かなきゃ行けない(アナライザー作成テンプレートには最初からそういう設定スクリプトが書かれてる)ファイルを参照プロジェクトを参照NuGetパッケージを参照

メタプログラミングはまだ妥協的• メタプログラミングでは• 生成元・生成結果両方見えてほしい• ただ、元と結果は明確に分離したいpublic class Sample1{public string Name { get; set; }public int X { get; set; }public int Y { get; set; }}public class Sample1 : INotifyPropertyChanged{public int X { get { return x; } set { SetProperty(ref x, value, xPropertyChangedEventApublic int Y { get { return y; } set { SetProperty(ref y, value, yPropertyChangedEventA#region NotifyPropertyChangedGeneratorpublic event PropertyChangedEventHandler PropertyChanged;private int x;private static readonly PropertyChangedEventArgs xPropertyChangedEventArgs = new Properprivate int y;private static readonly PropertyChangedEventArgs yPropertyChangedEventArgs = new Proper元情報生成結果• デバッグのためだけに見たい• コードを書く上ではノイズ

コンパイラーの負の遺産• Visual Studio/C#コンパイラー標準でない意味(再掲、抜粋)• 時代遅れになったら辞めればいい ⇔ 足すより減らす方が難しい• 経験則的な機能※も提供できる ⇔ 確実な機能しか提供できない• C# 7.0 提案• null非許容参照型• メソッドコントラクトコンパイラーは…拡張なら…この辺りの制限がきつくて足せない機能がある• 互換性を崩さないのが無理• 100%確実な判定が無理

null非許容参照型• 今のC#に欠けているもの値型参照型許容 T? T非許容 T これがないstatic void F(string s){if (s == null)throw new ArgumentNullException(nameof(s));}現状の書き方メソッドのシグネチャだけ見てnull許容かどうか判定できない煩雑

null非許容参照型• 今のC#に欠けているもの値型参照型許容 T? T?非許容 T T! null非許容参照型static void F(string! s){}C# 7.0 提案の書き方• 誰が見てもnull非許容• nullチェックはコンパイラー生成

null非許容参照型と互換性問題• F(string s) を F(string! s) に変えると、利用側を壊す• 今までnullチェックをサボっていた人がいたら• 例外catchで済ませている人がいたら• 標準ライブラリにちゃんと ! が付いてないと利便性半減互換性と利便性にトレードオフ

null非許容参照型と確実性• 一時的にnullになっていないといけない場面がある• 配列とか• 特に、コレクションの実装とかで• List<T>• HashSet<T>• この性質と、マルチスレッド動作が合わさると判定不能var array = new string[N];for (var i = 0; i < N; i++){array[i] = "";}この間は絶対にnull最初に大きめの配列をとっておいて、そのうちNマスだけ使う

null非許容参照型のアナライザー実装• アナライザーでなら実装簡単• 互換性が必要な場面では使わなければいい• 誤判定のリスク<ないことによる不便• 事実、実装がある• 今でも、ReSharperとかの静的解析ツールはやってる• C#チームも、一度アナライザーで実装してみてる• 実装: https://github.com/mattwar/nullaby• その報告: https://github.com/dotnet/roslyn/issues/2119• もしかしたら、C# 7.0はこのまま、一部アナライザー実装になるかも

言語機能のアナライザー実装の課題• 一部分だけアナライザー？• string! ←こういう書き方を解釈するのはコンパイラー機能• string! の非nullを解析するのはアナライザー• 機能がon/offできるコンパイラー機能？• 同じバージョンのC#を使っているはずでも、コンパイルできる環境とできない環境ができる挙動的にはかなりキモい

まとめ• C# 6.0、Compiler Platform• IDEとの連携性が実は主役、C# 6.0はちょい役• Platform化の恩恵• 皆が作れる• Code-Awareである• ライブラリ固有の事情をくめる• 経験則• 特定文脈によった解析とか、誤判定(判定漏れ)が許容されうる• C#公式機能ですらアナライザーベースになるかも• null非許容参照型 (あとたぶん、メソッドコントラクトも)

Movatterモバイル変換

Change Language

.NET Compiler Platform

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

Similar to .NET Compiler Platform

More from 信之岩永

.NET Compiler Platform

Editor's Notes

Movatterモバイル変換

.NET Compiler Platform

Recommended

More Related Content

What's hot

Viewers also liked

Similar to .NET Compiler Platform

More from 信之 岩永

.NET Compiler Platform

Editor's Notes

More from 信之岩永