Calypso and the future of D

Elie Morisse via Digitalmars-d digitalmars-d at puremagic.com
Sun Jan 25 07:16:25 PST 2015


On Sunday, 25 January 2015 at 10:18:34 UTC, Walter Bright wrote:
> Next, in the README example, it says:
>
>   $ clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o
>   $ ar rcs libshowcase.a showcase.cpp.o
>   $ ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ 
> showcase.d
>
> Where's Calypso in that?

On Sunday, 25 January 2015 at 11:12:50 UTC, Kelly wrote:
> Calypso is part ldc2 and, as far as I understand it, is invoked 
> via the "-cpp-args" command line arg.

-cpp-args is only to pass arguments to Clang while generating the 
precompiled header.

Calypso registers itself as a "language plugin", and when parse.c 
encounters « import (ABC) xxx.yyy; » it asks the registered 
plugins if one of them handles the "ABC" language id. If that's 
the case it lets the plugin create the Import symbol by itself, 
for instance Calypso creates a cpp::Import which derives from 
Import and has a completely different load() method, which won't 
look for modules in .d files but inside the PCH generated by 
Clang.

Here's the LangPlugin interface:

class LangPlugin
{
public:
     // returns -1 if said lang isn't handled by this plugin, or 
its id number
     // to be passed to createImport otherwise
     virtual int doesHandleModmap(const utf8_t *lang) = 0;

     virtual Modmap *createModmap(int langId,
         Loc loc, Expression *arg) = 0;

     // returns -1 if said tree isn't handled by this plugin, or 
its id number
     // to be passed to createImport otherwise
     virtual int doesHandleImport(const utf8_t *tree) = 0;

     virtual Import *createImport(int treeId,
         Loc loc, Identifiers *packages, Identifier *id,
         Identifier *aliasId, int isstatic) = 0;

     // ===== - - - - - ===== //

     virtual Expression *getRightThis(Loc loc, Scope *sc, 
AggregateDeclaration *ad,
         Expression *e1, Declaration *var, int flag = 0) = 0;

     // ===== - - - - - ===== //

     virtual FuncDeclaration *buildDtor(AggregateDeclaration *ad, 
Scope *sc) = 0;
     virtual FuncDeclaration *buildCpCtor(StructDeclaration *sd, 
Scope *sc) = 0;

     // ===== - - - - - ===== //

      virtual CodeGen *codegen() = 0;
};

getRightThis, buildDtor and buildCpCtor are needed because they 
"override" the global functions with the same name.

About Andrei's query about a general plugin system I don't know 
how one could be architectured. The hooks created for Calypso are 
specific to C++, so the help I could get is simply to be open to 
those hooks (which aren't really intrusive and don't uglify the 
code except for one or two that could probably be done 
differently: 
https://github.com/Syniurge/Calypso/commit/debd83f49363bf6805573d141a62b25d068d8a14)

The problem with arbitrarily limiting where the hooks could occur 
is that it might force the plugins to copy and paste redundantly 
the base functions, which is bad especially for big semantic() 
functions.

This probably deserves more thought, maybe there's a more elegant 
way waiting to be found.


More information about the Digitalmars-d mailing list