Scheibenweise

Inhaltsverzeichnis

Die Grundidee von Microsofts Roslyn-Projekt ist, den Compiler als Dienst zu betrachten, der alle Schritte von der Quelltext-Analyse bis zum Generieren des .Net-Bytecode (CIL-Code) ausführt. Jede einzelne Phase ist dabei separat steuerbar, sodass man jederzeit Informationen abrufen kann. Ziel ist, die Analyse des Quellcodes und der Programm-Semantik per .Net-APIs zur Verfügung zu stellen.

Roslyn ist momentan noch in einem frühen Stadium und unterstützt als Sprachen nur C# und VB.Net, soll aber später in das offizielle Visual Studio integriert werden und die vorhandenen Compiler ersetzen. Dass es Microsoft damit ernst meint, zeigen die prominenten Teammitglieder wie Eric Lippert und Anders Hejlsberg, die „Erfinder“ von C#, Delphi und Turbo Pascal.

Eine Vorversion der Software hat Microsoft auf der letzten Build-Konferenz vorgestellt und Ende 2011 zum öffentlichen Download angeboten [a]. In der derzeitigen Version ist sie als Erweiterung in Visual Studio 2010 SP1 integrierbar und damit Interessenten zugänglich.

Die neuen Compiler für die beiden Sprachen sind wie die Vorgänger als klassische Kommandozeilenprogramme (csc.exe und vbc.exe) und per API aufrufbar. Dabei sind sie erstmalig in sich selbst geschrieben und nicht in C++ wie bisher, wie ein Teammitglied in seinem Blog angibt.

Über APIs Zugriff auf die Dienste

Für alle Grundschritte stellt Roslyn APIs bereit: die syntaktische/lexikalische Analyse des Quelltexts, die semantische Analyse der abstrakten Syntaxbäume (AST) sowie schließlich die Übersetzung in den CIL-Code und die Erzeugung des nativen Codes für die Ausführung.

Es gibt eine Vielzahl von internen Projekten, die sich damit verwirklichen lassen, denn bei komplexen Programmen braucht nicht nur der Compiler detaillierte Kenntnisse über den Code, sondern auch der Debugger für die Codefluss-Analyse und die Entwicklungsumgebung, beispielsweise für die Refaktorierung des Quelltexts. Auch weitere Tools profitieren davon, so das Analysetool PREsharp, das Microsoft intern verwendet, um eine mit dem C++-PREfast vergleichbare statische Fehleranalyse von Quelltext vorzunehmen.

Aus statischen Sprachen C# und VB.Net macht die Roslyn-Architektur dynamische Sprachen, die zur Laufzeit Code erzeugen und ausführen können. Damit entfällt der Nachteil einer Compiler-Sprache gegenüber interpretierten Skriptsprachen; der Quelltext ist ohne weitere Verarbeitungsschritte sofort lauffähig. Der Vorteil des Compilers bleibt bestehen; viele Prüfungen stellen sicher, dass das Programm formal fehlerfrei ist.

Mehr Infos

Installation von Roslyn

Voraussetzung für die Installation von Roslyn ist Windows 7 oder Server 2008 R2 (mit der Developer Preview Build 8102 von Windows 8 hat’s auch geklappt). Ferner benötigt man das Visual Studio 2010 mit SP1 ab der Professional-Version. Die kostenlose Express-Version reicht nicht. Wer Roslyn nur eine begrenzte Zeit ausprobieren möchte, wäre mit der Trial-Version der Professional-Variante gut bedient [d]. Da Roslyn die Oberfläche der IDE erweitert, ist noch das „Visual Studio 2010 SP1 SDK“ erforderlich.

Die Vorversion installiert zusätzlich Beispielprogramme und eine sehr gute und umfassende Dokumentation [b]. Beides demonstriert die Funktionsweise und eignet sich als Grundlage für erste eigene Schritte. Die Quelltexte der Beispielprogramme und die zugehörige Dokumentation gibt es jeweils in einer Variante für C# und VB.Net.

Eigene Programme lassen sich zudem um eine Skriptsprache für Makro-Funktionen erweitern; so wie Browser JavaScript zur Erweiterung ihrer Möglichkeiten oder Emacs und AutoCAD Lisp-Varianten nutzen.

Mit Roslyn sind „Two-Way-Tools“ möglich wie Borlands Delphi – was nicht verwundert, war doch Anders Hejlsberg früher dort Chefentwickler. Auch Werkzeuge für die UML-Modellierung, die in der Ultimate-Variante von Visual Studio enthalten sind, lassen sich realisieren. Mit einfachen Tools kann man dort eine Oberfläche schnell „zusammenklicken“, das Tool generiert dafür Quelltext. Nach einer manuellen Änderung darin lässt sich die Oberfläche aber nicht mehr in grafischer Form editieren. Two-Way-Tools halten den generierten Quelltext und die grafische Repräsentation auf einem Stand, man kann dadurch jederzeit hin- und herwechseln.

Für Tool-Hersteller dürfte Roslyn interessant sein, um Erweiterungen für das Visual Studio anzubieten. Einige Beispiele:

• Ressourcen- und Performance-Analyse
• Dotfuscatoren
• Source-Beautifier
• Integration von TRACE-Ausgaben

Auf der letzten Build-Konferenz hat Anders Hejlsberg in einer Demo gezeigt, wie einfach man mit Rosyln-APIs Quelltext von einer .Net-Sprache in eine andere überführen kann. In seinem Beitrag hatte er VB-Quelltext in äquivalenten C#-Code umgesetzt.

Funktionen und Aufbau

Roslyn bietet APIs für vier Bereiche: Compiler, Scripting, Workspace und Services. Die ersten beiden hängen nicht von der IDE ab, damit erstellte Software benötigt kein installiertes Visual Studio. Der dritte ist für Codeanalyse und Refactoring und der letzte für IDE-Merkmale wie IntelliSense des Editors und zur Erweiterung des Visual Studio vorgesehen (s. Abb. 1).

In der Vorgehensweise unterscheidet sich Roslyn nicht von einem klassischen Compiler, denn auch er basiert auf einem Scanner zum Zerlegen des Quelltexts und einem Parser zur Verarbeitung der Programmstruktur. Ungewöhnlich ist, dass dabei viele Zusatzinformationen erhalten bleiben, die andere Compiler während der Verarbeitung verwerfen. Compiler merken sich normalerweise nur Name und Zeilennummer der Quelltextdatei, um Fehler auszugeben.

Roslyn hingegen behält bei der Analyse des Sourcecodes alle Informationen, um aus den internen Strukturen wieder den Original-Quelltext zu rekonstruieren. Dabei finden Syntax-Bäume Verwendung (Klasse SyntaxTree), die alle Informationen aus dem Quelltext aufnehmen, selbst Kommentare und Whitespace, für die Rosyln den Term Trivia benutzt. Praktisch ist, dass sich Syntax-Bäume selbst dann erzeugen lassen, wenn der Quelltext syntaktisch nicht fehlerfrei ist.

Mit dieser Klasse lässt sich mit der Methode ParseCompilationUnit zur Laufzeit Quellcode analysieren, die resultierenden Objekte kann man manipulieren und damit einen Quelltext vor dem Zurückschreiben umstrukturieren.

Die Verarbeitung von Quelltext als abstrakte Syntaxbäume lässt sich in etwa vergleichen mit einer XML-Verarbeitung (s. Abb. 2). Dabei ist die Anwendung der APIs einfach. Um einen Syntaxbaum zu untersuchen, lässt sich die Klasse SyntaxWalker nutzen, sozusagen als Iterator über die Baumstruktur. Zum Bearbeiten existiert die Klasse SyntaxRewriter, die Änderungen ausführt und daraus wieder Quelltext produziert – vergleichbar mit dem Original, inklusive aller Kommentare.

Spannend ist das semantische Modell (Klasse SemanticModel). Es lassen sich alle Deklarationen, die Typen von Variablen oder die Gültigkeitsbereiche ermitteln, oder mit der API für „Control and Data Flow Analysis“ die Ablaufstruktur eines Programms bestimmen, beispielsweise an welchen Stellen eine Methode mit return verlassen wird.

Wenn im Quelltext mehrfach die Variable i steht, muss es sich nicht um dieselbe Variable handeln, sie könnte in unterschiedlichen Gültigkeitsbereichen vorkommen. Das ist mit einer rein lexikalischen Analyse nicht erkennbar. Ebenso wenig wie unbenutzte Variablen oder solche mit ausschließlichen Zuweisungen von konstanten Werten zu finden sind.

Hier überschneidet sich Roslyn mit der Reflection aus .Net, die auf der Ebene kompilierter Elemente (Assemblies) arbeitet. Während die Reflection in einer eingeschränkten Sichtweise nur den CIL-Code untersuchen kann und damit zur Laufzeit Informationen beispielsweise über Klassen und Typen von Rückgabewerten liefert, stellt Roslyn die Zusammenhänge zum ursprünglichen Quelltext her und ist damit deutlich flexibler.

Im Gegensatz zum Compiler, wo sich Informationen nur abrufen lassen, kann man mit Roslyn die Visual-Studio-Oberfläche erweitern und damit die IDE um Werkzeuge anreichern. Die könnten dann Auskunft über Programmelemente geben oder helfen, den Quelltext umzuformen oder neu zu strukturieren.

Bei allen Vorzügen hat Roslyn auch einige Einschränkungen. Obwohl C++ in einer leicht abgespeckten Form Mitglied der .Net-Familie ist, unterstützt Roslyn diese Sprache nicht.

Einschränkungen und Grenzen

C# und VB sind syntaktisch und semantisch eher schlicht und tragen nicht wie C++ den Ballast von 30 Jahren mit sich, der vieles verkompliziert. Dazu gehören beispielsweise Makros, die Quelltext extrem unübersichtlich machen können und Analysen deutlich erschweren. Es bleibt unklar, ob es je eine Roslyn-Version für C++ geben wird, Microsoft hat sich dazu noch nicht geäußert. Gleiches gilt für F#.

Hinzu kommt, dass die Unterstützung des Sprachumfangs von C# und VB.Net in der aktuellen Vorversion noch unvollständig ist. Der Dokumentation ist zu entnehmen, dass in C# noch Finalizer, Iteratoren und mehrdimensionale Arrays fehlen. Bis Roslyn als Ersatz für die offiziellen Compiler zum Einsatz kommen kann, hat das Team noch viel Arbeit vor sich.

Die neue Offenheit hat ihre Grenzen, denn die APIs der Roslyn-Compiler sind nicht erweiterbar. Es ist somit nicht möglich, Roslyn andere – als die von Microsoft vorgegebenen – Informationen zu entlocken, auch wenn diese als „Zwischenschritte“ intern vorhanden sein müssten. Zudem spricht zurzeit wenig dafür, dass die Redmonder den Quelltext von Roslyn veröffentlichen.

Fazit

Selbst mit der quelloffenen „GNU Compiler Collection“ hätte man es schwer, den Funktionsumfang von Roslyn nachzubauen, denn üblicherweise ist es nicht vorgesehen, einzelne Komponenten wie Syntax- oder Kontrollfluss-Analyse separat zu verwenden. Mit Roslyn sind es nur wenige Zeilen Code.

Gerüchten zufolge soll das finale Roslyn erst nach Visual Studio 2012 kommen. Es ist zu hoffen, dass Microsoft die Unterstützung für die übrigen, in Visual Studio enthaltenen .Net-Sprachen wie C++ und F# nachreicht.

Matthias Withopf

arbeitet als selbstständiger Softwareentwickler.

Alle Links: www.ix.de/ix1204122

(wm)