GSoC 2019 - Integrating libSyntax with the compiler pipeline

[Vinicius_Vendramini]

Hi all,

I'm interested in applying for GSoC using the project of integrating libSyntax with the compiler pipeline. I've sent a few pull requests to Swift before, so I'm already reasonably familiar with the process, and I already have some notion of the compiler's codebase and how it's structured.

From what I understand, the Parser is currently responsible for generating both the AST and the libSyntax tree. The idea for this project would be to implement a new converter responsible for turning the libSyntax tree into an AST, thus removing this task from the Parser.

What I would like to know is: what approach could I take to implement this incrementally?

What I understand from an initial look at files like ParseExp.cpp is that the Parser generates libSyntax nodes at the same time as it generates AST nodes. Therefore, as I implement the converter, I could make the parser use it to convert its libSyntax node into an AST node (instead of creating both by hand). Once all the nodes have been implemented, it'd be a matter of transferring the conversion from the parser into a separate step.

Does that sound about right?

[rintaro (Rintaro Ishizaki)]

@Vinicius_Vendramini

I'm interested in applying for GSoC using the project of integrating libSyntax with the compiler pipeline.

Great!

@Vinicius_Vendramini

What I would like to know is: what approach could I take to implement this incrementally?

That is a good question. Actually, that will be a challenge in this project.

@Vinicius_Vendramini

What I understand from an initial look at files like ParseExp.cpp is that the Parser generates libSyntax nodes at the same time as it generates AST nodes. Therefore, as I implement the converter, I could make the parser use it to convert its libSyntax node into an AST node (instead of creating both by hand). Once all the nodes have been implemented, it'd be a matter of transferring the conversion from the parser into a separate step.

I think that works. But it should be noted that the syntax rule has circular dependencies. For example, closure expression syntax depends on decl syntaxes that depends on expression syntax including closure expression syntax.

[Vinicius_Vendramini]

Thanks for the reply (and sorry for the delay)!

@rintaro

I think that works. But it should be noted that the syntax rule has circular dependencies. For example, closure expression syntax depends on decl syntaxes that depends on expression syntax including closure expression syntax.

Good point! I think I can try to create the not-yet-implemented nodes the old way and send them to the converter as parameters. Something like:

converter.createClosure(closureSyntax, declExpression)

Maybe that'll allow me to make some more progress until I can convert all expression syntaxes. When that happens I'll probably end up having to change everything that's left at once, but at least it won't be as much work.

Even if this doesn't work, I think I can probably convert some leaves before having to send some really big patches...

Thanks for the help!