#compiler-design 

[Red-Green Trees: an Overview. Six months ago I dug into Roslyn’s… | by Bayastan | Jun, 2025 | Medium](https://medium.com/@krendelia2021/red-green-trees-an-overview-17bae2d84e8c)

[[抽象構文木]]というか[[具象構文木]]の実装方法の一つ。

構文の途中で差し込まれたコメントなどのトリビアなどを保持して、完全なソースコードに戻せるけど実行効率などをよくしたままにできるやり方。

部分的に構文木を書き換えたりするとソースコードのロケーション情報がずれたりするので、文字幅とオフセットを別々に持たせるというやり方をしている

ながいけどこれがわかりやすい

[Ruby Parser開発日誌 (19) - 最高の構文木の設計 2024年版 - かねこにっき](https://yui-knk.hatenablog.com/entry/2024/08/23/113543)

[[C#]]のRoslynで提案されたもので、[[rust-analyzer]]とかでも使われている

- Green Treeが構文的に意味のある単位でのツリーで、Childrenを持ち、Spanの絶対位置ではなく幅を持つ
- Red Treeは必要に応じて構築される木で、Green Nodeへの参照と親への参照、ドキュメントトップからのSpanの先頭位置を持つ

これで、SpanはRed-GreenTreeの組み合わせでアドホックに生成できるから、部分的な木の差し替えとかにも対応しやすくてうれしい

## これってRustでもうちょっとシンプルに作れんのか


[[Rust]]で普通にSyntax Tree作ってると、Recursiveなenumを経由して作るのが普通なわけだが、適当なid-arena的仕組みで管理している限りは、普通のSyntax TreeがGreen Tree


愚直に参考にされているやつを使うと、Tagged Unionをゼロから再実装するみたいなことになるので、Rustのenum as Tagged Unionの構造を有効活用したくね？


Rust Analyzerだと文字列だけじゃなくSyntax TreeまでInterningされてるらしい（Rust規模のコードベースなら確かに有効かも）

[rust-analyzer/docs/dev/syntax.md at c9109f23de57359df39db6fa36b5ca4c64b671e1 · rust-lang/rust-analyzer · GitHub](https://github.com/rust-lang/rust-analyzer/blob/c9109f23de57359df39db6fa36b5ca4c64b671e1/docs/dev/syntax.md)

というかrowanそのままつかえばいいのかな

[GitHub - rust-analyzer/rowan](https://github.com/rust-analyzer/rowan)