Updating Pull Requests for DDMD

Making your pull requests work with DDMD

There are a few common changes that will require additional work to make DDMD correctly compile.

Adding a new global type, function etc

To do this, an entry for the new symbol will need to be added to 'magicport.json'. This file has a top-level member named "mapping" with a list of D files to be generated. Select the entry that corresponds to the module the symbol belongs in (identified by the "module" members) and add the new symbol to the "members" list. The order in the list will determine the position in the file. To identify the symbol, use the 'kind' of the symbol followed by the name.

eg. to add a new class type 'EnumThing' to the top of 'ddmd.enum', the correct mapping entry would be "module" : "denum". The member list would need to be modified like this:

    "members" :
    [
+       "struct EnumThing",
        "struct EnumDeclaration",
        "struct EnumMember"
    ]

The 'kind' names are:

• struct - C++ class or struct
• function - function OR #define macro
• enum - enum
• variable - global variable OR #define constant
• typedef - C++ typedef which maps to a D alias

Anonymous enums are identified by "enum" followed by the identifier of the first member. eg "enum IgnoreNone".

#if blocks are identified by "version" followed by the full string of the first member. eg "version typedef dinteger_t"

Using symbols previously unused in a module

DDMD does not use public imports, so each module must be imported into every module that uses any symbols from it. The C++ headers basically all import each other, so new errors may appear when building DDMD for the first time even if the C++ diff didn't add any #includes.

To correct this, add an entry to the "imports" list in the importing module's mapping entry. The "imports" list does not need to be sorted.

Deleting global symbols

If this is done, the corresponding entry will need to be removed from magicport.json

Defining new types

In some cases, it will be necessary to add types to either the "basicTypes" or "structTypes" lists. The "basicTypes" list should be used for enums or aliases of actual basic types. In many cases the converter will automatically detect new struct/class types and it won't be necessary to update the list.

Adding new virtual functions

By default, all classes and methods are marked as final in the generated code. If a method needs to be overriden, the overridden function needs to be in the "overriddenfuncs" list, and the base class needs to be in the "nonfinalclasses" list.

Variable shadowing

D does not allow local variable or parameter shadowing, but C++ does. These errors should be fixed in the C++ source by removing the shadowing.

Implicit narrowing integral conversions

D is much stricter than C++ here. These errors should be fixed in the C++ source, at least by adding casts.

Comments inside expressions/statements

The converter does not allow many cases of comments in places where a statement or declaration can't go.

eg

if (x /* comment */)
{
}

Do not add these to the C++ source.

Splitting statements or expressions with the preprocessor

D, and the converter, do not allow code like this:

if (x)
{
}
#if SOMETHING
else
{
}
#endif

Do not add new code that does this to the C++ source, instead use #if only in places where D's version is acceptable.