Issue 12668 - std.traits.functionAttributes should use the new getFunctionAttributes trait.

[ghost]

https://issues.dlang.org/show_bug.cgi?id=12668

This requires dlang/dmd#3506 before it will pass the autotester.

[ghost]

I've left the demangleFunctionAttributes intact in case we ever need to use it in the future. But if we want to do it we could remove it.

[ghost]

Ah I've just realized I can use a CTFE function with a static foreach.

Edit: Updated to use CTFE.

[monarchdodra]

Did you notice it's failing?

[ghost]

This requires dlang/dmd#3506 before it will pass the autotester.

[monarchdodra]

This requires dlang/dmd#3506 before it will pass the autotester.

Derp. I saw it the first time, and then forgot about it :/

[ghost]

Anyway no reason to keep this open while it's waiting for the DMD pull.

DMD pull was merged. Awaiting review & green on this one.

[monarchdodra]

Seems like it is now failing at the unittest stage.

[ghost]

Gonna investigate. Strange because it worked a few days ago locally.. something must have changed.

[ghost]

It appears the old FunctionTypeOf trick was in there to support opCall. I've left it in as a special-case, but I'll have to investigate some more to see if I can support this directly with the getFunctionAttributes trait. In the meantime the tests should start passing now.

[ghost]

The reason why I've left nogc here instead of moved it somewhere else (which would have made the order nicer with [trusted, safe, system]), is because I want to keep backwards compatibility if any code ever stored nogc as a uint field somewhere (it's might be rare, but I don't want to introduce hard to track bugs).

[ghost]

I need to fixup getFunctionAttributes w.r.t. @System first, let me close this for a while.

[ghost]

Updated. Hopefully it should pass now, locally it works.

[ghost]

Ah interesting, there's some DerivedFunctionType template magic in std.typecons. I'll have to see what can be fixed here.

[ghost]

I've added a workaround.

@9rnsr: You probably wrote that DerivedFunctionType code. Do you think it's ok that I had to remove @system when applying the attribute (see the diff)? If not then maybe I could change how SetFunctionAttributes works instead so existing code continues to work.

[monarchdodra]

LGTM, but the any subtlety here could have gone over my head.

In particular: Is @system an actual attribute? I know you can "mark" a function as @system, but I always figured it was an override to prevent a template from being inferred @safe...

I guess the question is really for the getFunctionAttributes implementation...

[ghost]

In particular: Is @System an actual attribute?

Sure, it just happens to be the default. Let's ping @9rnsr though.

[monarchdodra]

Sure, it just happens to be the default. Let's ping @9rnsr though.

Hum...

struct S
{
  void foo()         {}
  void bar() @system {}
}

void main()
{
    pragma(msg, typeof(S.foo).stringof);
    pragma(msg, typeof(S.bar).stringof);
}

void()
@system void()

Now I'm even more confused. Seems that @system is an attribute that may or may not exist, but we don't really care either way, since the only thing that matters is rather "the abscense of @safe/@trusted"?

Given the above test, it seems inconsistent that your tests pass:

    static assert(functionAttributes!(S.noF) == FA.system); 
    static assert(functionAttributes!(typeof(S.noF)) == FA.system); 

I think there is an inconsistency here between what the actual attributes are, and what attributes get mangled in the name?

[ghost]

Hum...

See dlang/dmd#3533 (comment)
dlang/dmd#3506 (comment)
dlang/dmd#3501 (comment)
dlang/dmd#3501 (comment)

[monarchdodra]

I see...

[mihails-strasuns]

Auto-merge toggled on

[mihails-strasuns]

Looks good and latest auto-tester results look green

[ghost]

Thanks.