[PATCH] D104777: PR50767: clear non-distinct debuginfo for function with nodebug definition after undecorated declaration

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D104777#2837794 <https://reviews.llvm.org/D104777#2837794>, @dblaikie wrote:

> In D104777#2837347 <https://reviews.llvm.org/D104777#2837347>, @brunodefraine wrote:
>
>> In D104777#2836669 <https://reviews.llvm.org/D104777#2836669>, @dblaikie wrote:
>>
>>> Yeah, all that sounds reasonable to me - @brunodefraine could you look into supporting nodebug in a similar way as @aaron.ballman has described here?
>>
>> Since the debuginfo for `use()` is slightly affected by the `nodebug` version of `t1()` that follows it, I can see how this back propagation is perhaps dangerous. Checking that `nodebug` is the same on all declarations of a function is a way to prevent this.
>>
>> But when discussing the PR, @probinson wrote "I'm inclined to think we want this to work" and I can see what he means from the use case where I observed the bug. If you don't want debuginfo for the implementation of `t1()`, it should be fine to annotate just the function definition in an implementation file, not the declaration in a header, since the debuginfo of the implementation is not of the caller's concern. But `nodebug` as it exists **does** affect the debuginfo of callers as well, so I cannot really express that I don't want debuginfo for the implementation of a function and leave its callers unaffected?
>
> I can see the convenience there, to be sure, being able to put the attribute directly on the function you want to debug - but consistency in how attributes are handled (admitedly this isn't a strong consistency - some are handled this way, some aren't) & consistently seeing the same state for an attribute for a given function seems useful.
>
> @probinson - thoughts?

To me, this is the key bit:

> But `nodebug` as it exists **does** affect the debuginfo of callers as well, so I cannot really express that I don't want debuginfo for the implementation of a function and leave its callers unaffected?

because it **does** affect the callers, the programmer introducing the API should be aware of that. Making this case an error helps them to understand that this attribute is actually a part of their API and not an implementation detail, and silently applying the attribute may cause hard-to-debug problems for them after deployment of their API.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104777/new/

https://reviews.llvm.org/D104777