Difference between revisions of "GDC/CurrentReleaseTasks"

From D Wiki
Jump to: navigation, search
m (Overview)
(Library)
Line 57: Line 57:
 
=== Library ===
 
=== Library ===
 
* Improve build scripts for libphobos
 
* Improve build scripts for libphobos
* Allow for building libphobos outside the normal GCC build (still requires GCC sources).
+
* <strike>Allow for building libphobos outside the normal GCC build (still requires GCC sources). </strike> (done)
 
* Remove all *.di handling in build scripts, don't install modules as *.di in the system.
 
* 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
 
* Test builds on all primary supported platforms, secondary platforms are also nice: https://gcc.gnu.org/gcc-5/criteria.html

Revision as of 15:40, 2 August 2015

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 ensuring 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:
  • 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.
  • 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). (done)
  • 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.