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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
