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 contributing to windows bindings easier #118749

Merged
merged 3 commits into from
Feb 15, 2024
Merged

Conversation

ChrisDenton
Copy link
Member

This PR does three things:

  • Automatically sorts bindings so contributors don't have to. I should have done this to begin with but was lazy.
  • Renames windows_sys.lst to bindings.txt. This matches the windows-rs repository (and repos that copy it). I believe consistency with other projects helps get people orientated.
  • Adds a README.md file explaining what this is about and how to add bindings. This has the benefit of being directly editable and it's rendered when viewed online. Also people are understandably jumping right into the windows_sys.rs file via ripgrep or github search and so missing that it's generated. A README.md alongside it is at least slightly more obvious in that case. There is still a small note at the top of windows_sys in case people do read from the beginning.

None of this has any impact on the actual code generated. It's purely to make the new contributors workflow a bit nicer.

@rustbot
Copy link
Collaborator

rustbot commented Dec 8, 2023

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 8, 2023
@smmalis37
Copy link
Contributor

Is there anything checking that all the generated bindings are actually being used? Should there be?

@ChrisDenton
Copy link
Member Author

I would prefer to keep churn to a minimum with the bindings themselves therefore I'm inclined to not be too strict here unless it significantly affects compile times. Ideally it would already have all the necessary bindings so contributors didn't ever have to generate new ones. I think of it like the libc crate. The only reasons we're not using the actual windows-sys crate is because of concerns over the vendored size and a few differences in types.

@bors
Copy link
Contributor

bors commented Jan 13, 2024

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

@thomcc
Copy link
Member

thomcc commented Feb 1, 2024

I'm going to be away for a few months, so I'm rerolling my PRs so that folks don't have to wait for me. Sorry/thanks.

r? libs

@rustbot rustbot assigned cuviper and unassigned thomcc Feb 1, 2024

To add bindings, edit `bindings.txt` then regenerate using the following command:

./x run generate-windows-sys && ./x fmt library/std
Copy link
Member

Choose a reason for hiding this comment

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

Maybe the generator should run its output through rustfmt too?

Copy link
Member Author

@ChrisDenton ChrisDenton Feb 14, 2024

Choose a reason for hiding this comment

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

I think that would be good but what worried me is if people are using any kind of special arguments to x. It would be quite hard to make sure we're invoking x fmt the same way whereas it's easy enough for the user to adapt the commands if they have any special requirements. Maybe I'm being overly cautious though.

Also a minor issue is that there's a bit of complexity to ensure we run the right x fmt for the platform and the way this worked has changed a few times in the past so we may need to adapt to future changes (e.g. the x/x.ps1 split). That said, it does seem to have settled down now.

Copy link
Member

Choose a reason for hiding this comment

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

OK, no big deal either way.

@@ -1,7 +1,6 @@
--out windows_sys.rs
--config flatten std
--filter
// tidy-alphabetical-start
Copy link
Member

Choose a reason for hiding this comment

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

If this is the file that people actually edit, then isn't it still desirable for it to remain sorted?

Whereas, it doesn't seem important to me whether the generated file is sorted or not.

Copy link
Member Author

@ChrisDenton ChrisDenton Feb 14, 2024

Choose a reason for hiding this comment

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

Ah, to be clear this PR now sorts bindings.txt automatically not the generated file. I mean, we can make Rust do this itself well enough (in this specific case) whereas human contributors have tended to get sorting wrong a fair bit. This is possibly also an argument that tidy should at least produce better error messages than "line not in alphabetical order" but fixing that would be a bigger job 😀

Copy link
Member

Choose a reason for hiding this comment

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

Oh, I missed that it was writing it back after sorting, not just in memory for the next stage.

@cuviper
Copy link
Member

cuviper commented Feb 14, 2024

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Feb 14, 2024

📌 Commit 846315d has been approved by cuviper

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 14, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 15, 2024
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#111106 (Add known issue of let binding to format_args doc)
 - rust-lang#118749 (Make contributing to windows bindings easier)
 - rust-lang#120982 (Add APIs for fetching foreign items )
 - rust-lang#121022 (rustdoc: cross-crate re-exports: correctly render late-bound params in source order even if early-bound params are present)
 - rust-lang#121082 (Clarified docs on non-atomic oprations on owned/mut refs to atomics)
 - rust-lang#121084 (Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`)
 - rust-lang#121098 (Remove unnecessary else block from `thread_local!` expanded code)
 - rust-lang#121105 (Do not report overflow errors on ConstArgHasType goals)
 - rust-lang#121116 (Reinstate some delayed bugs.)
 - rust-lang#121122 (Enforce coroutine-closure layouts are identical)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 0977600 into rust-lang:master Feb 15, 2024
11 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Feb 15, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 15, 2024
Rollup merge of rust-lang#118749 - ChrisDenton:winsys, r=cuviper

Make contributing to windows bindings easier

This PR does three things:

- Automatically sorts bindings so contributors don't have to. I should have done this to begin with but was lazy.
- Renames `windows_sys.lst` to `bindings.txt`. This [matches the windows-rs repository](https://github.com/microsoft/windows-rs/blob/8e71051ea8a57594478e585d2740126893f9dbb7/crates/tools/sys/bindings.txt) (and repos that copy it). I believe consistency with other projects helps get people orientated.
- Adds a `README.md` file explaining what this is about and how to add bindings. This has the benefit of being directly editable and it's rendered when viewed online. Also people are understandably jumping right into the `windows_sys.rs` file via ripgrep or github search and so missing that it's generated. A `README.md` alongside it is at least slightly more obvious in that case. There is still a small note at the top of `windows_sys` in case people do read from the beginning.

None of this has any impact on the actual code generated. It's purely to make the new contributors workflow a bit nicer.
@ChrisDenton ChrisDenton deleted the winsys branch February 15, 2024 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-windows Operating system: Windows S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants