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

Fix the style for bitflags! #503

Merged
merged 3 commits into from
Feb 23, 2017
Merged

Fix the style for bitflags! #503

merged 3 commits into from
Feb 23, 2017

Conversation

TethysSvensson
Copy link
Contributor

Prefer libc_bitflags! over bitflags!. Prefer libc::CONSTANTS over
writing the constant manually.

This makes #501 unnecessary, since upstream now contains the O_TMPFILE constant.

@TethysSvensson
Copy link
Contributor Author

TethysSvensson commented Jan 31, 2017

This compiles for me on as many targets as master, though I have not run any tests locally. Can I assume that Travis does a sufficient job for testing?

It does not compile on the following targets (and neither does master):

  • *-apple-ios
  • *-linux-android
  • *-linux-androideabi
  • *-linux-musleabi
  • *-linux-musleabihf
  • *-netbsd
  • mips*
  • powerpc*
  • s390x*

I will try to do follow-up PRs to fix that.

Copy link
Contributor

@fiveop fiveop left a comment

Choose a reason for hiding this comment

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

Great work. Is there a reason why some of the bitflags! instances were not converted to libc_bitflags!?

@TethysSvensson
Copy link
Contributor Author

Yes, I used libc_bitflags! whenever all of the definitions are currently present in the libc crate under the correct types and used bitflags! in the remaining places.

I also might have missed a few of the definitions, but I think I got most of them.

@kamalmarhubi
Copy link
Member

This is great!

@idolf

I used libc_bitflags! whenever all of the definitions are currently present in the libc crate under the correct types and used bitflags! in the remaining places.

How are you deciding what the correct types are?

@TethysSvensson
Copy link
Contributor Author

@kamalmarhubi: This PR did not change any of the types. I meant "correct types" as being the same ones as currently used in nix. For instance libc::EPOLLIN is available as a libc::c_int, but nix uses it as a u32.

@homu
Copy link
Contributor

homu commented Feb 17, 2017

☔ The latest upstream changes (presumably #515) made this pull request unmergeable. Please resolve the merge conflicts.

@TethysSvensson
Copy link
Contributor Author

Rebased on top of current master.

@TethysSvensson TethysSvensson force-pushed the bitflags branch 2 times, most recently from 0387331 to 3433d9b Compare February 17, 2017 14:17
@homu
Copy link
Contributor

homu commented Feb 17, 2017

☔ The latest upstream changes (presumably #508) made this pull request unmergeable. Please resolve the merge conflicts.

Mathias Svensson added 2 commits February 19, 2017 08:41
Prefer libc_bitflags! over bitflags!. Prefer libc::CONSTANTS over
writing the constant manually.
@TethysSvensson
Copy link
Contributor Author

Rebased again. Is there any chance that you could get this merged soon, so I won't have to keep rebasing it?

This is not only a style fix, but actually fixes at least one constant (O_TMPFILE) and most likely more.

Copy link
Member

@kamalmarhubi kamalmarhubi left a comment

Choose a reason for hiding this comment

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

Only one change required: changing the representation type of EpollFlags.

The rest are just thoughts on more stuff we can do in the same vein after changing libc.

const O_CLOEXEC = 0o02000000,
const O_SYNC = 0o04000000,
const O_CLOEXEC = libc::O_CLOEXEC,
const O_SYNC = libc::O_SYNC,
const O_PATH = 0o10000000,
Copy link
Member

Choose a reason for hiding this comment

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

not blocking this PR, but if these are missing in libc would you be up for adding them there? Then we could have a followup PR here to use only libc-defined constants.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree that it would be a good idea to get more constants upstream and to fix their types. I've already filed rust-lang/libc#503 and rust-lang/libc#504 which is progress towards this goal.

That being said, my main interest in this was to fix the value of O_TMPFILE in a non-hacky way. I might do more at a later stage, but I have less motivation to do so now that my use-case has been fixed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh and rust-lang/libc#506 as well.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah no pressure to do it, and certainly not on this PR. I'll probably do a few myself over the coming days.

const O_CLOEXEC = libc::O_CLOEXEC,
const O_SYNC = libc::O_SYNC,
const O_NDELAY = libc::O_NDELAY,
const O_FSYNC = libc::O_FSYNC,
const O_SHLOCK = 0x0000080,
const O_EXLOCK = 0x0000020,
const O_DIRECT = 0x0010000,
Copy link
Member

Choose a reason for hiding this comment

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

same here re non-libc constants & defining them upstream

const MS_RELATIME = libc::MS_RELATIME,
const MS_KERNMOUNT = libc::MS_KERNMOUNT,
const MS_I_VERSION = libc::MS_I_VERSION,
const MS_STRICTATIME = libc::MS_STRICTATIME,
const MS_NOSEC = 1 << 28,
const MS_BORN = 1 << 29,
Copy link
Member

Choose a reason for hiding this comment

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

again :-)

src/sys/epoll.rs Outdated
const EPOLLMSG = libc::EPOLLMSG as u32,
const EPOLLERR = libc::EPOLLERR as u32,
const EPOLLHUP = libc::EPOLLHUP as u32,
const EPOLLRDHUP = libc::EPOLLRDHUP as u32,
const EPOLLEXCLUSIVE = 1 << 28,
Copy link
Member

Choose a reason for hiding this comment

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

once more!

Copy link
Member

@kamalmarhubi kamalmarhubi left a comment

Choose a reason for hiding this comment

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

forgot to actually include the comment on the requested change!

src/sys/epoll.rs Outdated
@@ -8,21 +8,21 @@ use ::Error;
bitflags!(
#[repr(C)]
pub flags EpollFlags: u32 {
Copy link
Member

Choose a reason for hiding this comment

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

let's change this to libc::c_int.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

@kamalmarhubi
Copy link
Member

This is basically done modulo changing the type of EpollFlags. Could

@kamalmarhubi
Copy link
Member

Argh. I am failing at GitHub today...

@kamalmarhubi kamalmarhubi reopened this Feb 22, 2017
@kamalmarhubi
Copy link
Member

@idolf thanks. Not sure if it'll pass or require dropping as u32 on the definitions. Let's find out!

@homu r+

@homu
Copy link
Contributor

homu commented Feb 22, 2017

📌 Commit 716f216 has been approved by kamalmarhubi

@kamalmarhubi
Copy link
Member

@idolf thanks. Not sure if it'll pass or require dropping as u32 on the definitions. Let's find out!

@homu r+

@homu
Copy link
Contributor

homu commented Feb 22, 2017

💡 This pull request was already approved, no need to approve it again.

@homu
Copy link
Contributor

homu commented Feb 22, 2017

📌 Commit 716f216 has been approved by kamalmarhubi

@homu
Copy link
Contributor

homu commented Feb 22, 2017

💡 This pull request was already approved, no need to approve it again.

@TethysSvensson
Copy link
Contributor Author

I'm guessing it probably will.

@TethysSvensson
Copy link
Contributor Author

Yep, it did not build locally. I've pushed a fixed commit now.

@TethysSvensson
Copy link
Contributor Author

Can I tell homu to retry, or do you need privileges for that?

@homu retry

@kamalmarhubi
Copy link
Member

@homu retry

@kamalmarhubi
Copy link
Member

@homu r+

@homu
Copy link
Contributor

homu commented Feb 23, 2017

📌 Commit 51b5eac has been approved by kamalmarhubi

homu added a commit that referenced this pull request Feb 23, 2017
Fix the style for bitflags!

Prefer `libc_bitflags!` over `bitflags!`. Prefer `libc::CONSTANTS` over
writing the constant manually.

This makes #501 unnecessary, since upstream now contains the `O_TMPFILE` constant.
@homu
Copy link
Contributor

homu commented Feb 23, 2017

⌛ Testing commit 51b5eac with merge 1fb5fe3...

@kamalmarhubi
Copy link
Member

kamalmarhubi commented Feb 23, 2017

Can I tell homu to retry, or do you need privileges for that?

I guess I can't either. I think retry only applies to the same commit.

Anyway, thanks again!

@homu
Copy link
Contributor

homu commented Feb 23, 2017

💥 Test timed out

@kamalmarhubi
Copy link
Member

@homu retry

homu added a commit that referenced this pull request Feb 23, 2017
Fix the style for bitflags!

Prefer `libc_bitflags!` over `bitflags!`. Prefer `libc::CONSTANTS` over
writing the constant manually.

This makes #501 unnecessary, since upstream now contains the `O_TMPFILE` constant.
@homu
Copy link
Contributor

homu commented Feb 23, 2017

⌛ Testing commit 51b5eac with merge 2bb718c...

@homu
Copy link
Contributor

homu commented Feb 23, 2017

☀️ Test successful - status

@homu homu merged commit 51b5eac into nix-rust:master Feb 23, 2017
@TethysSvensson TethysSvensson deleted the bitflags branch February 23, 2017 18:58
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.

4 participants