On 1/25/2015 7:16 AM, Elie Morisse wrote:
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.
You see, nobody understands where Calypso is! Is it part of clang, part of ldc,
a standalone tool?
I feel like Noah:
https://www.youtube.com/watch?v=bputeFGXEjA 1:44
Calypso registers itself as a "language plugin", and when parse.c encounters
parse.c is not part of my project. Where is parse.c?
« 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.
A language plugin plugging into where?
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.
