AaronBallman wrote: > > > @AaronBallman @erichkeane Thank you for your comments. There's a question > > > here about whether to report an error or a warning here, and you're in a > > > divided opinion. My opinion is that it is better to use the error report > > > here. Because these are two mutually exclusive conditions, it is > > > semantically unreasonable to set tail calls or non-tail calls even if the > > > program is still run after a warning is reported. I still want to hear > > > your opinions. Regarding the PR title, PR information, test cases, I will > > > fill in the next submission. Thank you both again. > > > > > > I favor an error in this case because the whole point to `musttail` is to > > _ensure_ that a tail call happens or the code is rejected: > > https://clang.llvm.org/docs/AttributeReference.html#musttail > > I lean towards warning, only because the behavior is 'ignored attribute', and > those are a specific warning group.
CC @haberman as the original author of `musttail` in Clang, but 8344675908424ee532d4ae30e5043c5a5834e02c was the original commit for this feature and *every* misuse of `musttail` is an error there. What I recall of the design discussion is that guarantees are the entire point to using the attribute. In fact, the original commit message said "The attribute is applied to a return statement (not a function declaration), and an error is emitted if a tail call cannot be guaranteed, for example if the function signatures of caller and callee are not compatible. Guaranteed tail calls enable a class of algorithms that would otherwise use an arbitrary amount of stack space." https://github.com/llvm/llvm-project/pull/134465 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
