chore(github): regression test select packages with rustc stable

[thoughtpolice]

Summary: This will help make sure people don't add features to packages that are already tested as stable.

GitHub Issue: #265

[stepancheg]

CI for starlark needs to be added to starlark-rust repository.

There is internal CI for starlark-rust on stable, but not on GitHub.

Overall, I don't think this is the way. We frequently move code between crates, so this will only add more work to developers, not getting us closer to making buck2 work on stable.

[thoughtpolice]

I can totally add a stable check (and MSRV check too) to starlark rust, that's no big deal, and probably a good idea. I only used it here because I knew it was a crate that worked, actually; I have another patch to make e.g. host_sharing stable compatible, but haven't filed it yet, so I couldn't have added it.

Also, to be precise, I don't think that this really prevents moving code between crates; or stopping anyone from creating new crates (which often seems to happen during refactoring). What it does do is make a very loud "boom" sound when a crate that already compiles with stable rust suddenly becomes a crate that requires unstable rust. Because Buck is only tested with nightly compilers by everyone in practice, I think there needs to be some way to keep track of this right now, whether it's just ripgrep'ing for #![feature( blocks in every crate dir, or actually running cargo build. I just chose cargo build here.

My impression is that fixing #265 wasn't really a major goal for anyone else right now, so I'd be alone in trying to fix it, but I wanted to start making headway; I was going to start submitting PRs for various crates first, actually, and I figured I'd submit this first to get it in place so that my subsequent PRs could mark crates as "complete" when I got done (such as host_sharing) and help tick the checkboxes.

Would it be acceptable if we could turn this into something that just alerts me, or alternatively doesn't fail the CI? I'm fine with reactively fixing the occasional failure after the fact — assuming the normal PR review process, of course. Or do you think this is all blocked by a bunch of stuff and it doesn't matter anyway, and I should just submit PRs normally?

[stepancheg]

I can totally add a stable check (and MSRV check too) to starlark rust

Only if you have time. It won't regress anyway.

What it does do is make a very loud "boom" sound when a crate that already compiles with stable rust suddenly becomes a crate that requires unstable rust.

I'd argue #[feature(...)] to the crate is the same boom.

My impression is that fixing #265 wasn't really a major goal for anyone else right now

Yes, buck2 on stable rust is not on our roadmaps unfortunately. Nobody is working on it.

Would it be acceptable if we could turn this into something that just alerts me, or alternatively doesn't fail the CI?

I'll put it this way. Either

• we make it work on stable and switch CI to stable
• or don't setup CI

That intermediate state where we got extra code to maintain, but did not achieve the goal of working on stable, has negative value.

I believe, significant amount of work needed to make it work on stable. For example, recently we started using feature(provide_any). It does not require language features, and can be forked into buck2 repository or a third-party some third-pary library can be used, but as I said, significant amount of work.

If you only want to alert yourself, you can set up a job in a separate repository: checkout buck2 repository, run cargo check for certain crates, run it once an hour.

That said, PRs which remove unstable features are welcome. At least to understand better how far we are from being able to work on stable.

[thoughtpolice]

Good points — I think the separate repository idea makes the most sense for now. Thanks!