Consider depending on the libc crate from its git repo

[SteveLauC]

A lot of Nix PRs are blocked by a libc release, which actually slows down our pace, what about we directly depend on its git repository, and only switch to the crates.io version when we are gonna release a new version of Nix.

[dependencies]
libc = { git = "https://github.com/rust-lang/libc", features = ["extra_traits"] }

Then once our contributor's libc PR gets merged, they can also make their Nix PR ready, I think this will make their contributing experiences better.

It seems that we used to do this, but we pin it to a specific commit, is there any drawback if we don't pin it? One thing I can imagine is that if GitHub action caches our dependency, no Cargo.toml change, no Cargo.lock change, then new libc PRs will never be visible to our CI, though I doubt if this will happen given that we didn't explicit cache anything in our ci.yml

[Alan Somers]

Yeah, it's fine to do that. We used to do it all the time, but don't anymore just because the pace of new development in libc has slowed. I still favor pinning a specific revision, however, just so builds will be reproducible. New PRs can always change that revision as-needed.