Fix Issue 20074 - header file generation doesn't include attributes with CallExp

[RazvanN7]

I don't know why the constructor body is being outputted. Can anyone shed some light on this?

[dlang-bot]

Thanks for your pull request and interest in making D better, @RazvanN7! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20074	normal	header file generation doesn't include attributes with CallExp

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#10217"

[rainers]

The comment three lines above the patch says that omitting the attributes is deliberate. It actually can be a bit annoying in the error message if the problem is not related to inferred attributes.

[RazvanN7]

I agree, but on the other hand it may lead to (falsely) uncompilable code. Consider:

class C
{
    this() @safe
    {
        () @trusted
        {
            int a; int*p = &a;                                                                                                                
        }();
    }   
}

Without this patch, the compiler will omit @trusted and generate uncompilable code from perfectly fine code.

The comment baffled me also, but I think that this is the correct way to go.

[rainers]

You should adjust or remove the comment in that case. A compromise might be to emit explicitly specified attributes, but not inferred ones. But the required info might not exist and not worth the complications to add.

[rainers]

I don't know why the constructor body is being outputted. Can anyone shed some light on this?

That's because a ctor has no return type and is falsely considered auto here;

dmd/src/dmd/hdrgen.d

Line 1487 in 84bcc67

if (!tf.next || f.storage_class & STC.auto_)

[RazvanN7]

That's because a ctor has no return type and is falsely considered auto here;

So this is also a bug.

[rainers]

So this is also a bug.

Yes, and if it is fixed the test case in this PR might get removed. So I suggest adding a test where the function literal is used by some declaration, e.g. as a template argument.

[RazvanN7]

@rainers I changed the test case so that the literal is inside a templated function's body and also I deleted the comment. I think this is good to go now.

[rainers]

Thanks

[RazvanN7]

Maybe it's time we get this in?

[PetarKirov]

Thanks for the reminder ;)