Replace use of libdparse with dmd as a library in dfix
Description
dfix is a tool to automatically upgrade code to new features. It uses libdparse - a third party implementation of a D lexer+parser - to obtain an AST which it then uses to generate the fixed code. Since libdparse has a different implementation from the reference D frontend, every time a parser change occurs, libdparse and (likely) its dependencies need to be updated.
The project aims at using the dmd-as-a-library package, which shares its implementation with the reference D compiler, to substitute the use of libdparse in dfix.
What are rough milestones of this project?
- Create a fork of dfix and set up a testing pipeline.
- Use dmd-as-a-library to obtain the AST.
- Rewrite the existing visitors to use the generated AST
- Write more potential fixes for existing deprecations.
- Integrate the fork in the original dfix repo.
How does this project help the D community?
Ideally, every deprecation or language change should be accompanied by a tool that automatically updates the wrong code to the correct code. Having dfix use the compiler as a library will make it easier for compiler devs to implement the fixes and thus improving the user experience when deprecations/language changes occur.
Recommended skills
Knowledgeable with AST, parsers, compilers. Prior experience with D/C/C++/Java OOP Visitor pattern Git Tenacity, patience Motivated and able to work independently.
Point of Contact
@RazvanN7
hi @RazvanN7 this project looks really interesting and impactful. i am interested in compilers and have a understanding of compiler concepts and I have prev experience in writing object oriented code in c++ through various projects.I am currently going through the repo and understanding the astbase.d and how the visitor patterns are implemented in dmd. I would really love to make this project alive and kicking once again under saoc
Hi @saeitoshi-10 ! dfix does use libdparse but for the auto-correction with respect to preview flags, the tool is quite outdated. Also, this project does not a have a big priority from the Dlang Foundation perspective. However, there is a project which is more impactful and is actually on the list of priority projects - the separating semantic routines from ast nodes one( there is a directory in this repo that describes the project, please take a look at it ). Additionally, the work done for this project overlaps with what you would have done if you chose the dfix one. This will give a good overview of the compiler codebase and is a good ramp up for future compiler contributions.
I suggest you look at that project and consider applying with that one.
Hi @RazvanN7 so i went through the semantic separation for AST nodes project and in the progress tracker i saw that attrib.d and dclass.d are marked in progress but there is no progress tracker or any reference for how much work has already been done on it. it would have been great if i had the list of pr's so that i could get an idea of what we have to work on further to decouple semantic part completely. Also are the files marked done need any further review for any prospective semantic method or import removal?Also thank you for suggesting this project, i am really liking the project :).
hi @RazvanN7 i had some queries about the project. so first should i try to minimise the dependencies of a file not tracked by the project(like hdrgen.d) on a file tracked by the project(like mtype.d).Second is there a regular channel of correspondence to you