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

Replace winapi with windows-sys #712

Merged
merged 2 commits into from
Nov 28, 2022
Merged

Conversation

hotate29
Copy link

Thanks for contributing to chrono!

  • Have you added yourself and the change to the changelog? (Don't worry
    about adding the PR number)
  • If this pull request fixes a bug, does it add a test that verifies that
    we can't reintroduce it?

@hotate29
Copy link
Author

hotate29 commented Jun 16, 2022

This change brings MSRV to (maybe) 1.35.0. For the time being, wait for CI.

@hotate29 hotate29 changed the title Replace winapi Replace winapi with windows-sys Jun 16, 2022
@esheppa
Copy link
Collaborator

esheppa commented Jun 17, 2022

Hi @hotate29 - thanks for this PR. If possible could you do the following:

  • Update the CI yaml to use 1.46 so we can ensure the CI does pass
  • Add an empty feature called "winapi" to avoid potential breakage (as per here)

As far as the increase in MSRV we may be better off waiting for an 0.5 release. It looks like debian stretch is at version 1.41 but I don't have a good understanding of where might be currently using version 1.32 and also packaging chrono or packages that depend on chrono. Also from a quick investigation windows-rs lists the rust-version as 1.46 which I think will likely be too much of an increase in the short term.

A solution in the meantime could be instead having a feature like "use-windows-rs" which would use "windows-rs" instead of "winapi" - however as per this issue I don't think this is currently possible.

Please let me know your thoughts?

@hotate29
Copy link
Author

  • Update the CI yaml to use 1.46 so we can ensure the CI does pass
  • Add an empty feature called "winapi" to avoid potential breakage (as per here)

Both done.

As far as the increase in MSRV we may be better off waiting for an 0.5 release. It looks like debian stretch is at version 1.41 but I don't have a good understanding of where might be currently using version 1.32 and also packaging chrono or packages that depend on chrono. Also from a quick investigation windows-rs lists the rust-version as 1.46 which I think will likely be too much of an increase in the short term

Ah, I completely forgot to check Cargo.toml in windows-sys...
As you pointed out, it may be abrupt to suddenly change MSRV to 1.46.0.

A solution in the meantime could be instead having a feature like "use-windows-rs" which would use "windows-rs" instead of "winapi" - however as per rust-lang/cargo#1839 I don't think this is currently possible.

I did not know about this issue. (Thanks for pointing it out!) Since there is no need to immediately switch to windows-sys, it may be safe to put this PR aside for now until there is more activity regarding version 0.5. (or close PR)

@hotate29 hotate29 force-pushed the replace-winapi branch 2 times, most recently from 2911b5c to d57099c Compare June 17, 2022 15:32
@djc djc added the API-incompatible Tracking changes that need incompatible API revisions label Jun 17, 2022
@djc
Copy link
Member

djc commented Jun 17, 2022

Would like to keep this open -- I tagged with the API-incompatible tag so we can easily find such changes in the future.

@hotate29
Copy link
Author

hotate29 commented Jun 18, 2022

  • Update the CI yaml to use 1.46 so we can ensure the CI does pass

@esheppa Do you mean to replace the part using 1.32 with 1.46?

@esheppa
Copy link
Collaborator

esheppa commented Jun 18, 2022

@hotate29 - yes in the .github/workflows/test.yml. It's up to you whether you wan't to do this as it might be a while before it gets merged, but its nice to leave it in a green state for when it gets picked up at the point that the MSRV can increase to >= 1.46

@hotate29
Copy link
Author

@esheppa I understand. thanks!

@kennykerr
Copy link
Contributor

Curious, what's holding this change up? Let me know if I can help.

@djc
Copy link
Member

djc commented Sep 6, 2022

@kennykerr what's the MSRV for the windows crates these days? We recently bumped to 1.38 but are being conservative about bumping more (probably the upper bound we'd consider is 1.48 at this point).

@kennykerr
Copy link
Contributor

The MSRV for windows-sys 0.36 is 1.46.

parking_lot has already moved to 1.49 so I would recommend that version if you're planning to switch. The next version of windows-sys will likely require 1.49 as well.

@djc
Copy link
Member

djc commented Sep 6, 2022

I think the limitation here is stable Debian, which IMO still affects a sizable contingent of downstream users. Anyway -- I'm generally interested in moving to windows-sys but this is why it's stalled. If you want to be lower in the stack than chrono, I think you should maybe be more conservative about MSRV bumps as well? 🙂

From my perspective (admittedly as a user of macOS on the desktop and Linux on servers -- and for other people I work with either at my day job or in OSS, it seems like Windows is a minority) I don't see a big benefit to switching away from winapi (and it's just a few small API calls, too) whereas I feel a substantial amount of responsibility towards downstream projects who want to serve users which have older compilers.

@kennykerr
Copy link
Contributor

Sorry for the delay - I lost track of this issue.

probably the upper bound we'd consider is 1.48 at this point

I just tested 1.48 and that works great: microsoft/windows-rs#2173

I'm happy to enforce that. As a practical matter, the current version of windows-sys works fine with 1.48 if you'd like to go ahead with that.

@esheppa
Copy link
Collaborator

esheppa commented Nov 19, 2022

Thanks for this @kennykerr.

@djc - what are your thoughts on using this in 0.5 with a MSRV of 1.48?

@djc
Copy link
Member

djc commented Nov 20, 2022

Yes, that seems fine. @hotate29 are you interested in rebasing this and updating it to bump the MSRV to 1.48?

@hotate29
Copy link
Author

@djc Yes, I am interested. I will work on that.

@hotate29
Copy link
Author

I have added an empty feature for compatibility (e65acd1), but if this change is included in the 0.5 release, I don't think it is needed.
Should I remove it?

@djc
Copy link
Member

djc commented Nov 21, 2022

Yes, please remove the empty feature.

Would you mind rebasing this so that there are two commits:

  • One to bump the MSRV and deal with all the fallout (clippy fixes etc)
  • Another separate one that actually replaces winapi

Can also do two separate PRs if that's easier for you (then we can squash while merging).

This would make it easier for me to review the changes.

@hotate29 hotate29 force-pushed the replace-winapi branch 2 times, most recently from 43bf05e to e0088e1 Compare November 21, 2022 16:46
@hotate29
Copy link
Author

I rebased.

@hotate29
Copy link
Author

Oops, found a mistake.

@hotate29
Copy link
Author

Fixed.

Copy link
Member

@djc djc left a comment

Choose a reason for hiding this comment

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

Looks great, one small issue to address, please fix it in the originating commit?

Cargo.toml Outdated
@@ -11,6 +11,7 @@ readme = "README.md"
license = "MIT/Apache-2.0"
exclude = ["/ci/*"]
edition = "2018"
rust = "1.48.0"
Copy link
Member

Choose a reason for hiding this comment

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

This is supposed to be rust-version and that only starts working after 1.56, so I don't think we should add it here.

Copy link
Author

Choose a reason for hiding this comment

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

Deleted. thanks!

Copy link
Member

Choose a reason for hiding this comment

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

So please squash this into the first commit?

Copy link
Author

Choose a reason for hiding this comment

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

Squashed.

Copy link
Collaborator

@esheppa esheppa left a comment

Choose a reason for hiding this comment

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

Thanks for this @hotate29 - apologies to ask you to rebase this again, but we have recently merged the past while of work from 0.4.x to main and if you can rebase this on the HEAD of main that would clean up the diff in this PR. (Separately if you could use git rebase -i to move 288a5a6 into ef3fe078 that would be great)

@hotate29 hotate29 force-pushed the replace-winapi branch 2 times, most recently from 3e1d064 to 313d125 Compare November 23, 2022 10:00
@hotate29
Copy link
Author

@esheppa Rebased.

Copy link
Collaborator

@esheppa esheppa left a comment

Choose a reason for hiding this comment

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

Thanks @hotate29 - there are just a few more changes I'd like you to take a look at if possible

@@ -36,7 +37,7 @@ pub(super) fn naive_to_local(d: &NaiveDateTime, local: bool) -> LocalResult<Date
tm_yday: 0, // and this
tm_isdst: -1,
// This seems pretty fake?
tm_utcoff: if local { 1 } else { 0 },
tm_utcoff: local as i32,
Copy link
Collaborator

Choose a reason for hiding this comment

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

do you mind using i32::from(local) here as per line 223 below?

tm.tm_hour as u32,
tm.tm_min as u32,
tm.tm_sec as u32,
tm.tm_nsec as u32,
);
)
.expect("invalid time");
Copy link
Collaborator

Choose a reason for hiding this comment

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

this could be cast to a LocalResult::None which would avoid the expect call (this is semantically sub-optimal, but is consistent with usage elsewhere):

let time = NaiveTime::from_hms_nano_opt(...).ok_or(LocalResult::None)?;

Copy link
Author

Choose a reason for hiding this comment

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

Pushed changes (will squash later).

Comment on lines +28 to +29
let datetime = tm_to_datetime(Timespec::now().local());
datetime.single().expect("invalid time")
Copy link
Author

Choose a reason for hiding this comment

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

An expectation is that the system will not return an invalid time.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This looks reasonable, in the case of now()

@hotate29 hotate29 force-pushed the replace-winapi branch 2 times, most recently from 823ecac to 221de6e Compare November 25, 2022 15:57
@esheppa
Copy link
Collaborator

esheppa commented Nov 26, 2022

Thanks for those fixes @hotate29 - if possible can you squash them down to the original two commits? We are using "Rebase and Merge" rather than "Squash and Merge" which is why we have to be a bit more picky about keeping all the commits within a given PR clean (I'll set up some docs on this to make it an explicit policy)

edit:
I've created #898 for this, mostly as a reminder to myself

@hotate29
Copy link
Author

@esheppa Squashed.

Copy link
Collaborator

@esheppa esheppa left a comment

Choose a reason for hiding this comment

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

Thanks for this @hotate29, looks good to go!

@djc djc merged commit 74ca661 into chronotope:main Nov 28, 2022
@hotate29
Copy link
Author

Thanks to all who worked on this PR!

@hotate29 hotate29 deleted the replace-winapi branch November 28, 2022 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API-incompatible Tracking changes that need incompatible API revisions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants