Skip to content

Should be possible to use the select!() macro within deny(unsafe_code) #32331

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.

Sign up for GitHub

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

Jump to bottom
Closed
Ms2ger opened this issue Mar 18, 2016 · 4 comments
Closed

Should be possible to use the select!() macro within deny(unsafe_code) #32331

Ms2ger opened this issue Mar 18, 2016 · 4 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Ms2ger
Copy link
Contributor

Ms2ger commented Mar 18, 2016

No description provided.

@steveklabnik
Copy link
Member

I believe that this is a duplicate, but I can't remember enough about the other bug :(

@mitaa
Copy link
Contributor

mitaa commented Mar 18, 2016

Did you perhaps think of #8472?

The unsafe block in select! could be annotated allow(unsafe_code), but that would require all crates the macro is used in to have feature(stmt_expr_attrs).

Another solution would be to move the unsafe block into a safe helper function...

@Ms2ger
Copy link
Contributor Author

Ms2ger commented Mar 18, 2016

Also, while deny(unsafe_code) is my primary concern, something that works with forbid too would be even better.

@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 24, 2017
@Mark-Simulacrum
Copy link
Member

select! macro is gone today and we have a way of doing this I believe (rustc_internal_unsafe or some similar attribute on macros)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@steveklabnik @Ms2ger @Mark-Simulacrum @mitaa