Add @attribute cctor/cdtor for C runtime constructors / destructors

[jpf91]

We'll probably need this for shared library support and it's useful for low level programming as well.

Usage:

import gcc.attribute;
@cctor extern(C) void ctorFunction(){}
@attribute("cctor", 1001) extern(C) void ctorFunction(){}

Would be nice if we could use @cctor and @cctor(1001) instead. Using this:

auto cctor(A...)(A args)
{
    return attribute("cctor", args);
}

auto cdtor(A...)(A args)
{
    return attribute("cctor", args);
}

Almost works. @cctor() and @cctor(1001) works, but @cctor compiles but does not apply the attribute. Any idea how to fix this? This problem probably affects all other attributes as well.

[jpf91]

@ibuclaw ping (one ping for all pull requests ;-)

BTW:

Almost works. @cctor() and @cctor(1001) works, but @cctor compiles but does not apply the attribute. Any idea how to fix this? This problem probably affects all other attributes as well.

__traits(getAttributes works fine in this case so the problem is in our gdc attribute code. In build_attributes (d-codegen.cc) attr is TOKtemplate/TemplateExp and attr->type->toDsymbol (0) returns null.

[ibuclaw]

@jpf91 - Apologies, I've been on a mini holiday, and just got back, I'll comb through what has been missed out shortly. :-)

[jpf91]

No need to apologize for holidays ;-) I just wanted to make sure there won't be too many changes on master before revisiting the pull requests to avoid some rebase / rewrite cycles :-)

[ibuclaw]

I'll OK this before I go.

It looks like this is just a clean copy from c-common, if there's been any update in the meantime, then it may need syncing across.

[jpf91]

Linking to dlang/dmd#6956
If that pull request is accepted, explicit attributes are less important. OTOH explicit attributes allow to use these constructors in non-betterC mode and it allows using multiple constructors per module, so this may be still useful to implement.

I guess I'll clean up this code this weekend, so we can finally close another way-too-old pull request.

[ibuclaw]

If that pull request is accepted, explicit attributes are less important. OTOH explicit attributes allow to use these constructors in non-betterC mode and it allows using multiple constructors per module, so this may be still useful to implement.

I'm not really a fan of -betterC - or rather - I'd prefer to call it anything but that. Things that it may promote I think are better served as individual codegen flags. If they collectively turn out to be useful, then give it a common name. But call it anything but betterC.

[JinShil]

Things that it may promote I think are better served as individual codegen flags.

Just wanted to say that I believe the same; -betterC is awfully blunt of an instrument.

[jpf91]

I think are better served as individual codegen flags.

Certainly. We all know Walter doesn't want to add many compiler flags to DMD but I hope we can at least get different flag variables for such things in the frontend and then DMD can still choose to only allow setting all of these at once using -betterC

If they collectively turn out to be useful, then give it a common name. But call it anything but betterC.

I don't particularly like the name either. We have -fstandalone but I think that should be even more restrictive (no C library dependencies on malloc, memset, ...). systemD is already taken, so I still like microD as a name (although it will certainly cause some childish jokes on reddit ;-).

[ibuclaw]

@jpf91 - Going anywhere with this? Or shall we wait and see whether pragma(crt_constructor) will get anywhere.

[jpf91]

Let's wait whether pragma(crt_constructor) get merged, no need to implement the same feature twice.