Preserve visibility of fn items without body #4858
Conversation
|
While I personally tend to agree with you that this isn't really a formatting concern, there's historically been a philosophy of utilizing rustfmt to clean things like this up (non-macro scenarios) and regularly occurring notions of doing it for more things as syntax evolves. As such I don't want to move ahead with this at this time, because if we do, then we'd never be able to revert back due to the formatting stability guarantee. The macro use case is insufficient justification for making the change categorically given the current formatting behavior around macro calls that's based on the user's chosen delimiters. The solution for those macro use cases is to brace delimiters when the args are invalid Rust syntax. |
No, and let's try to avoid making any more insinuations like that. The difference is the target/use case, where as noted in my previous comments, the driver for this PR is around args to macro calls that's part of a much broader lack of rustfmt support for macros and which has a standard, operable workaround. #4961 was not strictly related to macro calls, and had no such workaround. |
|
No, this is not only about macro call specifically. It also affects procedural macros like delegate-attr, and there is no workaround as well. |
|
Can you share a specific use case that isn't already supported with the latest version of rustfmt? The test cases you provided are already handled, and based on a cursory read of the docs for |
|
It seems that everything this PR tries to solve has already been solved by #4961. Sorry about that. But I hope you get that it was very frustrated that this PR was ignored for an extended time and another PR which basically did the same thing was accepted swiftly, then you claimed with a long reasoning that this PR is not going to be accepted because of the reasons that apply exactly the same way for the other PR that you accepted. |
It's not clear to me what outcome or benefits one could hope to realize from what seems like a continuation of the theme and tone of the accusation in your previous comment. I'm responding because I view your description as a rather inaccurate characterization of events that is missing important context, however, this will likely be my last response here as I simply don't have the bandwidth to go back and forth. For better or worse, rustfmt does generally have a heavy bias towards the status quo as I explained in my previous comment. However, we certainly can, and do, make (non-breaking) behavioral changes when needed, provided adequate context and rationalization are provided. This includes invalid syntax/grammatically irrelevant/etc. types of scenarios, with some recent examples being #4936 and #4960; both of which had associated clarity on their respective motivations. While I now understand that You seem to be of the belief that your PR was singled out or otherwise treated differently, and while I don't understand how you arrived at that conclusion, I am sorry you feel that way. rustfmt is not a massive project, but it's a fairly good sized one that's maintained by a single volunteer (me) with whatever amount of my personal time I can carve out. That means the amount of work always significantly exceeds capacity, which in turn means that lower priority items typically get less attention/require a longer lead time to resolution. As I noted above and previously in response to another of your comments, your PR was not very high on the priority list (due to the lack of clarity on your use case), and there's a massive backlog of issues and PRs that have been around and pending for far, far longer than yours. That spans requests/suggestions from both the community and members of the broader Rust team, and that actually includes a few from David that have been pending for years. The author of a report/request does not dictate priority, and any suggestion otherwise is patently false. |
|
Okay, thanks for the clarification. I thought the description was clear enough what it's trying to fix, and I didn't submit a new issue because I believe they are the same underlying issue, and I don't want to submit duplicate issues to add your work, but clearly that caused the reverse. |
|
No worries, and regardless of the path we took to get here, I'm glad this is finally sorted for you anyway! |
While it may not make sense in grammar to allow fn items without body to have visibility, as they are semantically only used as required methods in trait definition, I believe it is not on rustfmt to make this judgement. Such usage should be warned by clippy or rustc if desirable.
On the other hand, this may be used in macros, in which case the visibility is important, see for example #4631 and delegate-attr.
This fixes #4631.