.NET Compiler Platform

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.html
http://www.slideshare.net/ufcpp/csharp6
IDE前提の機能 .NET Compiler Platform

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

Demo
https://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標準)
コンパイルはできるんだけど、
人的ミスっぽいものを警告
アイテムテンプレートには多めに
出しておいて、最後に整理して消す
人それぞれで流儀が違うけど、
プロジェクト内ではそろえたい

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

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

プラットフォーム化
• こういうコード解析を誰でも作れるように
• 作れるもの:
• アナライザー(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 Gallery
Webサイト Visual Studio上から検索

配布: NuGet Gallery
Webサイト 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# Essentials
What C# 5.0を6.0化するのをガイドしてくれる
主に ?. と =>
Why C# 5.0→6.0の移行期にしか要らない
古い形式のままで使いたい人もいる
Owner Dustin Campbell
(C#/VBチームのプログラムマネジャー)
https://github.com/DustinCampbell/CSharpEssentials

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

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

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

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

(デモ用) FluentArithmetic
What デモ用に、最低限の機能に絞った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

(デモ用) FluentArithmetic
What デモ用に、最低限の機能に絞った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
0割りエラー
リテラル同士の演算を短縮

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

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

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

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

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

RecordConstructorGenerator
What 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()).ToArr
var 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, xPropertyChangedEventA
public int Y { get { return y; } set { SetProperty(ref y, value, yPropertyChangedEventA
#region NotifyPropertyChangedGenerator
public event PropertyChangedEventHandler PropertyChanged;
private int x;
private static readonly PropertyChangedEventArgs xPropertyChangedEventArgs = new Proper
private 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非許容参照型 (あとたぶん、メソッドコントラクトも)

.NET Compiler Platform

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to .NET Compiler Platform

Similar to .NET Compiler Platform (20)

More from 信之岩永

More from 信之岩永 (20)

Recently uploaded

Recently uploaded (16)