Skip to content

Style Guide prescriptions on ABI explicitness #199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
calebcartwright opened this issue Oct 30, 2024 · 4 comments
Open

Style Guide prescriptions on ABI explicitness #199

calebcartwright opened this issue Oct 30, 2024 · 4 comments

Comments

@calebcartwright
Copy link
Member

rust-lang/rfcs#3722 seems likely to land albeit for some future edition beyond 2024, and when it does I would propose we remove the existing ABI prescriptions from the Style Guide text

Formatters (at least rustfmt) do not necessarily have the relevant context to know whether formatting changes that involved the ABI would be semantics preserving, and the behavior that matched the "always be explicit" rule in the Style Guide did cause a couple of issues over the years (e.g. rust-lang/rustfmt#2908)

Once rust-lang/rfcs#3722 is enacted I think rustfmt should fallback to just maintaining ABI as it exists within the AST, and leave the consideration of whether an ABI has a default and/or is required as a lang item

@traviscross
Copy link

I propose we adopt @calebcartwright's proposal that:

rustfmt should fallback to just maintaining ABI as it exists within the AST, and leave the consideration of whether an ABI has a default and/or is required as a lang item

Included in this is that if there's not an ABI at all in the AST, the formatter should not add one.

On the matter of what prescriptions we should make in older editions about whether to add an ABI, I'd propose that the style guide can simply be silent about this since we now have a lang side lint in all editions against extern without an ABI, and we don't need to speak on the style side to things that are already handled via warning-level lang lints.

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Apr 16, 2025

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot
Copy link

rfcbot commented Apr 16, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @traviscross, I wasn't able to add the final-comment-period label, please do so.

@calebcartwright
Copy link
Member Author

calebcartwright commented Apr 17, 2025

Remind me, will the current process require 2 checkboxes or will it enter the final comment period as soon as any one person has checked their box?

Edit: never mind, I remember what we talked about on this topic when the team first changed to three members

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants