GDC/CurrentReleaseTasks

This is a list of project ideas for GDC - potential improvements, new features, et cetera. that are in relation to a release merge.

DMD 2.067

Overview

The release of D 2.067 marks the half-way point in DMD's development that moves towards having a frontend compiler that is entirely self-hosted, and has many glue methods stripped out and converted into either flat functions or double-dispatch Visitors.

From GDC's perspective, this means that many symbols that had to be provided for the sake of source compatibility are no longer required. So rather than the straight-forward conversion opted by upstream (examples including Statement::toIR -> Statement_toIR, Declaration::toDebug -> toDebug), instead the end-goal is to jump at the opportunity to rewrite many parts of the glue to be free of DMD-isms. This results in the following:

• Less code, no more horrible stubs.
• Frees us from the DMD naming conventions, such as toElem, toDebug, toImport.
• Potentially re-writing major parts to follow upstream GCC C++ conventions - as at the end of the day, a merge with GCC is still on the table, and on a personal note, I don't feel up to doing this again without ensure this is done.
• Allows a logic/flow that is more simplified and agrees more with our orientation around GCC trees.
• Did I already mention less code?

Remove DMD backend structures

• struct IRState:
  • Move methods to either IRVisitor in toir.c or as flat codegen routines in d-codegen.cc.
  • Move members of IRState to cfun->language, as there is only one IRState per function (unlike DMD).
  • Move members of struct Flow into struct binding_level as there is no distinction between the two for codegen purposes.
  • Calls to ::toElem should be replaced with 'toElem(NULL)' once all dependencies on the irs parameter have been removed.
• struct block:
  • Needs upstream co-operation: https://github.com/D-Programming-Language/dmd/pull/4854
  • Logical place to put all labels (both user and case) is in cfun->language
• struct dt_t:
  • Should just be a case of replacing all instances in d-todt.cc with tree
• struct Symbol:
  • Move members to struct lang_decl
• struct elem:
  • Should just be a case of replacing all instances in d-elem.cc with tree

Visitor conversions

• Not necessarily a straight conversion, must ensure that code follows GCC C++ coding conventions: https://gcc.gnu.org/codingconventions.html#Cxx_Conventions
• Names of visitors should match what it is generating code for, which may not necessarily be the name DMD gives it, some examples:
  •  ::toIR -> StatementVisitor -> stmt.cc
  •  ::toCtype -> TypeVisitor -> types.cc
  •  ::toElem -> ExpressionVisitor -> expr.cc
  •  ::toSymbol -> DeclarationVisitor -> decl.cc
• Some D frontend structures (Type, Declaration) have fields that are intended for backends to cache generated code, it should be possible to instead use a hash_map to cache these, allowing us to remove these backend-specific fields from the frontend.
  • Needs upstream co-operation: https://github.com/D-Programming-Language/dmd/pull/4569
• Provide a build_* function as the entry point for backend visitors.

Compiler

• Integrate GDC Visitors and structures into the GCC garbage collector.
  • Remove current workaround of using d_keep as a global bucket-list of all generated trees.
• Identify where functions need to be declared because they are called from the D frontend (d-glue.cc, d-typinf.cc).
  • Functions that don't touch any part of GDC/GCC should be moved into the frontend so as to be part of DDMD.
  • Functions that do touch GDC/GCC should be considered candidates for Target, however some exceptions to this are error routines.
• GDC sources have their dependencies managed automatically by the build systems. The D frontend sources should be fixed to work in the same way.
• d-dmd-gcc.h:
  • This needs to go, all GDC defined functions should have been moved to Target, all DMD defined functions need to be declared properly in frontend headers.
• d-todt.cc:
  • Remove the two-tier construction of initializers. This should be as straight-forward as possible, using CONSTRUCTOR_APPEND_ELT(elt, NULL, init) directly, rather than going through the dt_* helpers.

Library

• Improve build scripts for libphobos
• Allow for building libphobos outside the normal GCC build (still requires GCC sources).
• Remove all *.di handling in build scripts, don't install modules as *.di in the system.
• Test builds on all primary supported platforms, secondary platforms are also nice: https://gcc.gnu.org/gcc-5/criteria.html

General Tidy

Some low priority tasks that don't stop anything if not done.

• Source files should have clearer names, possibly removing the 'd-' prefix on sources that are frontend-specific, keeping the prefix for common frontend sources.
• Use .cc for sources that interact with the frontend, and .c for sources that are independent to GDC code generation.
• Add a namespace gcc { namespace d { } } for common codegen routines.
• Encapsulating codegen routines into Visitor classes where it makes sense.