Re-add forward declaration of _d_monitordelete

[ibuclaw]

Fixes bug introduced by #749

GDC compiles each module separately, unlike DMD, so gets hit by an 'undefined identifier' error. DMD doesn't get it because the private version of object.d is implicitly imported.

[braddr]

Auto-merge toggled on

[MartinNowak]

DMD doesn't get it because the private version of object.d is implicitly imported.

So should we compile object_.d separately?

[yebblies]

It's a weird situation, because object_.d is magic. This isn't a user-facing issue.

So should we compile object_.d separately?

If we are concerned about druntime modules compiling correctly with object.di, then we should probably compile them again object.di.

[rainers]

I wonder why we don't generate object.di from object_d. I tried that and compared the results:

• imports in object_.d: these should be made local
• other definition of size_t and ptrdiff_t (a comment in object.d says that the version in object.di does not work)
• function attributes on the left instead of the right (I think we might want to change that in the di file generation)
• most TypeInfo_* member overrides missing in object.di: this might cause wrong code if you derive from these and call super.method
• different type for TypeInfo_Class.defaultConstructor
• different return types for TypeInfo_Struct.xtoHash/xToString. Is this deliberate?
• missing members in MemberInfo_field in object.di: deriving from this will cause errors
• traceHandler declarations not in object.di: I guess these should be in another module anyway
• monitor functions/declarations not in object.di: I guess these should be in another module anyway
• event functions not in object.di: I guess these should be in another module anyway
• unittests leave an empty declaration block if annotated with pure/nothrow: compiles, but is ugly
• __ctfeWrite not in object.d: is this needed?
• different declaration of RTInfo!T
• @safe removed during conversion of '__traits(compiles, (T b) @safe { T a = b; })': bug?
• object_d uses a.dup, object.di uses .dup(a): I remember there are subtle differences, but do these apply to const(T)[], too?

Overall I think we gain by autogenerating object.di. That would still mean that there needs to be a separate build step when compiling without object_.d.

[ibuclaw]

If we are concerned about druntime modules compiling correctly with object.di, then we should probably compile them again object.di.

Or rely on gdc telling you your code is wrong... a couple of months after release. ;)

[yebblies]

Or rely on gdc telling you your code is wrong... a couple of months after release. ;)

Sure, either way works.