Quelques jours avant l’annonce officielle, Jb a organisé un Code Camp en Ardèche (près de Lyon) en invitant quelques personnes à travailler avec lui sur ce decompiler. L’idée était avant tout de passer un bon moment, de faire avancer découvrir le projet, mais aussi d’intéresser et d’encourager d’éventuels futurs contributeurs à rejoindre l’initiative.

Comme j’ai eu la chance de faire partie des petits privilégiés, je vais essayer de vous livrer mes impressions à chaud.

Déjà, belle surprise en recevant le mail d’invitation de Jb… Nous ne nous étions croisé qu’une soirée, à Paris, lorsqu’il était venu présenter Mono en novembre pour une de nos réunions ALT.NET. Dans un milieu où le copinage reste bien présent, ce genre de proposition dénote bien une certaine ouverture d’esprit, et un fort degré de coolitude. Merci. Robert Pickering faisait aussi partie des invités mais à part lui (et Jb, donc) je ne connaissais personne. Ce fut l’occasion de faire la connaissance de Patrice Lamarche, Mathieu Szablowski, Vincent Bourdon, et Sébastien Lebreton (auteur de réflexil). Sept personnes en tout ; soit un petit comité.

Je vous avouerai que j’étais un peu impressionné à l’idée de devoir rejoindre tout ce beau monde pour travailler sur un projet de cette envergure, dont la complexité moyenne dépasse quand même celle d’une application de gestion classique… Mais l’ambiance était excellente d’une part, et le sujet carrément intéressant d’autre part.

Ca ne suffit pas pour faire oublier qu’on est en train de faire du pair programming avec un mec de l’équipe Mono, mais ça aide un peu. En tout cas, ça fait vraiment plaisir de participer à un projet aussi motivant, avec des gens dont la simple proximité rend moins con. J’aurais aimé pouvoir travailler en pair avec tout le monde, mais j’ai principalement codé avec Jb et Rob. Et tout seul aussi, hein. Je n’ai pas envie de rentrer dans les détails techniques aujourd’hui, mais en gros, j’ai principalement travaillé sur la partie “décompilation C#”, et plus particulièrement sur les étapes de transformation de l’arbre syntaxique visant à faire apparaitre les structures de haut niveau du langage.

Le decompiler lit le code intermédiaire, en infère un Control Flow Graph, puis un AST assez brut dans lequel, par exemple, toutes les pre/post-tested loops sont modélisées sous la forme de statements while/do-while. Selon le langage, et selon la version du langage, il faudra ensuite exécuter une série d’analyses et de transformations sur cet arbre afin de reconnaitre les constructions spécifiques. Par exemple, et au hasard, le foreach.

Dans un vieux post, j’expliquais que le foreach en C# était syntaxiquement équivalent à :

IEnumerator<Jambon> enumerator = jambons.GetEnumerator();
try
{
	while( enumerator.MoveNext())
	{
		Jambon jambon = enumerator.Current;
		// Manger le jambon, miam, etc.
	}
}
finally
{
	IDisposable disposableEnumerator = enumerator as IDisposable;
	if(disposableEnumerator != null)
	{
		disposableEnumerator.Dispose();
	}
}

C’est donc le pattern qu’il faut identifier dans l’arbre, à quelques subtilités près. Ca m’a pris 3 bons jours, et c’est loin d’être terminé si on veut gérer tous les edge cases, allez donc savoir pourquoi. J’ai aussi travaillé avec Jb sur une implémentation sympa d’un “pattern matching du pauvre” en C#, joyeusement supprimée depuis… On cherche quelque chose de mieux. Mais ça permettait d’écrire des trucs rigolos du genre :

// Création du pattern
var matcher = Pattern.Match<Expression>()
					 .Is<MethodInvocationExpression>()
                     .Select(mie => mie.Method)
                     .Is<MethodReferenceExpression>()
                     .Tag(() => method_key, mre => mre.Method)
                     .Tag(() => target_key, mre => mre.Target);

// Compilation du pattern matcher pour récupérer un delegate qui pourra être mis en cache
// et invoqué avec de bonnes performances
var methodInvocationMatcher = matcher.Compile<Func<MatchResult, Expression, bool>> ();

// Exécution du pattern matching : on obtient un MatchResult
var result = Pattern.Run (MethodInvocationMatcher, expression);

// On peut maintenant, en cas de succès, travailler avec les valeurs qui ont été tagguée
// lors du pattern matching, si elles ont été trouvées
if (result.Success)
{
	Expression targetExpression;
    if (result.TryGetValue(target_key, out targetExpression))
    {
		// ...
	}

	MethodReference methodReference;
	if (result.TryGetValue(method_key, out methodReference))
	{
		// ...
	}
}

Le code du matcher pouvait être généré dynamiquement via System.Reflection.Emit, puis compilé pour obtenir un delegate capable d’être exécuté sans ruiner les perfs. Ca peut vous rappeler quelque chose… mais l’idée n’était pas de moi !

J’ai également eu l’opportunité de travailler avec Rob pour réaliser une version F# du matcher capable de détecter les foreach à titre d’essai. Pas vraiment l’initiation idéale à F# pour un profane comme moi, mais heureusement Rob a gardé le clavier durant la session. Ce fut pour moi l’occasion d’avoir un bon aperçu de la puissance du langage en matière de pattern matching et de tester rapidement pour la première fois l’intérop C#/F#.

Le projet en lui-même est à mon sens prometteur. Ce n’est pas juste un Reflector-bis. Il s’agit d’un framework de décompilation, libre et open source, qui peut être embarqué n’importe où. Ca ouvre pas mal de perspectives pour ceux qui travaillent sur des outils d’analyse statique de code par exemple. Jason Bock, auteur de CIL Programming avec lequel j’ai été méchant par le passé, va même jusqu’à trouver Cecil.Decompiler et sa licence MIT/X11 rassurants dans la mesure où la visibilité sur le devenir de Reflector est compromise.

Je ne suis pas sûr de vouloir crier hourra pour ça, mais ce dont je suis sûr, c’est que pouvoir disposer d’un décompilateur .NET open source, managé, qui repose sur une base solide, c’est tout bon. Si on considère en plus que Sébastien est déjà lancé à fond sur la réalisation d’une interface pour exploiter Cecil.Decompiler, dont le modèle d’extensibilité devrait être plus souple que celui de Reflector, c’est encore plus alléchant.

Quoi qu’il en soit, le decompiler en est à ses débuts. Il reste vraiment beaucoup de choses à faire, et ce à plusieurs niveaux :

• Core
• Support des langages : C#, VB, F#, etc.
• Interface, plugins

Mais au moins, vous savez à présent que le projet existe.