Convert shell scripts to Rust

[djkoloski]

I primarily dev on Windows, and I'd prefer to not have to use WSL to work on zerocopy.

[joshlf]

You'll need to resolve the merge conflicts first before we can see whether CI passes.

[joshlf]

I'm not familiar with Windows enough to know: Is there a way that we could keep a script that would be compatible with both Windows and POSIX, and would just be a thin wrapper around cargo run -p cargos? The latter is more verbose, which isn't great for the command we run the most frequently during development.

[djkoloski]

We could just publish this as a separate package and cargo install it. Another option would be to leave the cargo.sh file in place and make it a thin wrapper over cargo run -p cargos.

[joshlf]

I think the cargo.sh option makes sense. If we can make it so that its invocation is unchanged relative to what it currently is on main, that'd be ideal.

[djkoloski]

CI is failing with:

Run cargo run -p cargos -- +msrv check --tests --package zerocopy --target i686-unknown-linux-gnu  --verbose
error: failed to select a version for the requirement `regex = "=1.10.3"`
candidate versions found which didn't match: 1.8.4, 1.8.3, 1.8.2, ...
location searched: crates.io index
required by package `generate-readme v0.0.0 (/home/runner/work/zerocopy/zerocopy/tools/generate-readme)`

Although the regex dependency in generate-readme is specified as regex = "1", the Cargo.lock file is being generated on a later toolchain. regex has an MSRV of 1.65.0 as of regex-1.10.0 and an MSRV of 1.60.0 as of regex-1.8.0.

I don't think we should require the tooling to have the same MSRV as zerocopy and zerocopy-derive, but since it's in the workspace it gets added to package resolution. We could remove them from the workspace, but that would also be annoying and make the tools difficult to invoke. It would be nice if we could ignore these crates on +msrv, but I don't see a clear way to do that. We could just regenerate the Cargo.lock too, but that has the potential future problem if a tool adds a dependency that is never supported on the MSRV toolchain.

Another approach would be to bump the MSRV, but I don't know what the motivation for such a low MSRV is (1.56.0 is about two years and four months old). Up to you @joshlf how you want me to approach resolving it.

[joshlf]

Is there a reason not to leave this named cargo.sh? (I'll be honest I'm not sure what the etymology of cargos is as opposed to cargo)

[djkoloski]

It is an unfortunately mundane one. I originally kept it named cargo.sh and made cargo.bat to match. As it turns out though, when cargos runs a cargo command, Windows will run cargo.bat and not the installed cargo binary. So it effectively causes cargos to recursively call itself when it intends to invoke cargo. The easy fix was to use a different name, and I figured if I had to call it cargos on Windows then I should probably just make it uniform.

[joshlf]

Ah, that makes sense. My preference would be to keep cargo.sh named as-is, and rename the .bat file. Maybe win-cargo.bat? I'll leave it up to you what you want to name it.

[joshlf]

It looks like the invocation of cargo itself (e.g. the one inside cargos.sh) is using the default toolchain installed in the GitHub Action. You probably want to do cargo +stable like we do in cargo.sh on main.

[joshlf]

I pushed a new commit that should hopefully fix (some of) the CI errors. Feel free to delete it, squash it, etc.

Since these are in their own workspace now, can you update ci/check_fmt.sh to format that workspace as well?

[djkoloski]

ci/check_fmt.sh picks up the .rs files in the tools/ workspace, so no changes required there.

[joshlf]

Last comments that I'm aware of - once these addressed, we should be ready to merge.

Can you also squash all of these commits together? Otherwise, the entire set of commits shows up in the commit message that GitHub generates.