Skip to content
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

Decide whether blocks inside asm goto should default to safe #132078

Closed
joshtriplett opened this issue Oct 23, 2024 · 9 comments
Closed

Decide whether blocks inside asm goto should default to safe #132078

joshtriplett opened this issue Oct 23, 2024 · 9 comments
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@joshtriplett
Copy link
Member

asm goto requires labeled blocks, like asm!("...", foo = label { code() });.

We need to decide whether those labeled blocks are safe by default or whether they require explicitly writing safe or unsafe. I'm filing this issue for T-lang to decide which of those we want to go with.

Based on discussion with the Rust for Linux folks, I'm going to propose that these blocks should default to safe, and require an explicit unsafe if you want them to be unsafe.

I'm also going to propose that you shouldn't need nested braces if you want unsafe here: label unsafe { dangerous_code() } should work, rather than having to write label { unsafe { dangerous_code() } }.

@joshtriplett joshtriplett added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Oct 23, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 23, 2024
@joshtriplett
Copy link
Member Author

@rfcbot merge

@rfcbot
Copy link

rfcbot commented Oct 23, 2024

Team member @joshtriplett 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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Oct 23, 2024
@tmandry
Copy link
Member

tmandry commented Oct 23, 2024

I don't have a strong preference on defaulting to safe vs making you pick safe vs unsafe. If we add safe blocks later in an upcoming edition we can always require explicitness in the same edition.

I like the idea of avoiding an extra set of braces.

@rfcbot reviewed

@nikomatsakis
Copy link
Contributor

@rfcbot reviewed

This makes sense to me.

The ability to have safe blocks makes sense for folks building control-flow abstractions on top of inline-assembly. I am indifferent about whether or not it is the default, but if there is to be a default, I prefer safe ("fails open", as Josh said).

@traviscross
Copy link
Contributor

@rfcbot reviewed

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Oct 23, 2024
@rfcbot
Copy link

rfcbot commented Oct 23, 2024

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

@saethlin saethlin removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 26, 2024
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Nov 2, 2024
@rfcbot
Copy link

rfcbot commented Nov 2, 2024

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@traviscross
Copy link
Contributor

cc @Darksonn @ojeda @Amanieu

...on this now completed FCP.

@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Nov 14, 2024
@nbdd0121
Copy link
Contributor

Implementation merged: #131544

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

9 participants