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

Make from_bits in bitflags! safe; add from_bits_truncate #14208

Closed
wants to merge 1 commit into from

Conversation

aturon
Copy link
Member

@aturon aturon commented May 14, 2014

Previously, the from_bits function in the std::bitflags::bitflags
macro was marked as unsafe, as it did not check that the bits being
converted actually corresponded to flags.

This patch changes the function to check against the full set of
possible flags and return an Option which is None if a non-flag bit
is set. It also adds a from_bits_truncate function which simply zeros
any bits not corresponding to a flag.

This addresses the concern raised in
#13897

@omasanori
Copy link
Contributor

I've added test_from_bits yesterday so the test fails. I'm sorry. Rebasing and merging two tests into one must be fine.
BTW, I think adding tests for from_bits_truncate (including ones checking the difference in from_bits* family) would be better. What do you think?

@aturon
Copy link
Member Author

aturon commented May 14, 2014

@omasanori Yeah, I just noticed that with the Travis failure. I'm working on a revised patch that merges the tests and also adds tests for from_bits_truncate. Once it passes tests locally, I'll send it in. Thanks!

Previously, the `from_bits` function in the `std::bitflags::bitflags`
macro was marked as unsafe, as it did not check that the bits being
converted actually corresponded to flags.

This patch changes the function to check against the full set of
possible flags and return an `Option` which is `None` if a non-flag bit
is set. It also adds a `from_bits_truncate` function which simply zeros
any bits not corresponding to a flag.

This addresses the concern raised in rust-lang#13897
if (bits & !$BitFlags::all().bits()) != 0 {
::std::option::None
} else {
::std::option::Some($BitFlags { bits: bits })
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use std::option; could make it cleaner.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to import the module as part of the macro, since that can pollute the macro client's namespace -- so I think the type signature, at least, needs to stay as is.

(Note that macros.rs in libstd follows the same pattern.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, I have to admit I’m not used to declaring macros.

lnicola pushed a commit to lnicola/rust that referenced this pull request Mar 13, 2023
fix:add a case in which remainig is None in resolveing types when resolving hir path.

fix rust-lang#14030 The variable type is being determined incorrectly
This PR fixed a problem in which `go to definition` is jumping to the incorrect position because it was failing to resolve the type in case it defined in the module when resolving hir.
In addition, I added a test for this issue and refactored the related code.
This is my first PR and I am using a translation tool to write this text. Let me know if you have any problems.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants