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.
