Add release-plz for automatic releases.

[tgross35]

This is what cc-rs is using and should create a release PR whenever a change to master is made. If the branch is merged, it should publish the new version.

This will need the CARGO_REGISTRY_TOKEN github secret set, but I think omitting it for now might allow for a dry run.

[tgross35]

@NobodyXu I notice you always close then reopen the release PRs on cc-rs, e.g. rust-lang/cc-rs#1162. Any reason for this?

[NobodyXu]

@NobodyXu I notice you always close then reopen the release PRs on cc-rs, e.g. rust-lang/cc-rs#1162. Any reason for this?

That's because github does not run CI/pipeline on PRs created by bot, it'd require you to re-open it.

[tgross35]

Thanks, interesting. Looks like maybe that can be be configured https://github.com/orgs/community/discussions/55906#discussioncomment-9303330

[tgross35]

Hm, one other thing I'm not sure about is whether this will want to use 1.x.x rather than 0.1.x. I think it is safe to just try it and see what version it puts in the PR, it doesn't publish anything until the PR gets merged.

If it tries to use 1.x.x in the PRs and that can't be configured, we can just disable the automatic PR creation. The automatic release would still work whenever something that updates Cargo.toml version is merged.

[Amanieu]

Can you add a release-plz.toml to disable changelog generation and semver checks? This is an internal crate that should only be used as part of the rustc sysroot, not by users.

[tgross35]

Sure, added.

[Amanieu]

LGTM

@Mark-Simulacrum Could you help us set up this repo for release-plz like you did for rust-lang/cc-rs?

[Mark-Simulacrum]

Can you add a release-plz.toml to disable changelog generation and semver checks? This is an internal crate that should only be used as part of the rustc sysroot, not by users.

Given this, is there a reason we're publishing it to crates.io at all? I guess this feels like maybe it should be a submodule/subtree of rust-lang/rust?

re:token, see https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/compiler-builtins.20crates.2Eio, we'll need to wait on that before access can be shifted

[Mark-Simulacrum]

In any case, a token now exists in the repository secrets, should be the same as cc.

[tgross35]

Given this, is there a reason we're publishing it to crates.io at all? I guess this feels like maybe it should be a submodule/subtree of rust-lang/rust?

There are at least a handful of reverse dependencies https://crates.io/crates/compiler_builtins/reverse_dependencies. At least a few of those are because of rustc-dep-of-std (seems like you shouldn't have to explicitly list compiler_builtins), many of the others seem to be no_std support.

We also do say suggest using it as a dependency in the readme but only via git with no tag/rev. Maybe it would be better to suggest using the crates.io package but pinning to a specific version.

[Amanieu]

I think that long-term we're probably better off turning this into a submodule/subtree. I'm not sure how much work this work involve in bootstrap/cargo.

[Amanieu]

Unfortunately this seems to fail: https://github.com/rust-lang/compiler-builtins/actions/runs/10134695821/job/28021228181

[tgross35]

Ah just saw that, must be the libm cargo.toml. I'll check if there is a way to allow dirty.

[Amanieu]

I think we need to explicitly allow a dirty working directory when publishing.

[tgross35]

Sent #647