Add CI job for checking stdlib semver compatibility

[Kobzol]

This CI job installs the latest published version of cargo-semver-checks and then runs the x test std-semver-check bootstrap command added in #159671.

If csc finds semver breakage, the job will fail. If csc cannot parse the rustdoc JSON data (e.g. because the format was bumped), the job will print an error, but it will not fail.

One thing I'm not sure about is whether the stdlib will actually run into any breakages (or perceived breakages, from the perspective of csc), and how to deal with that, because then the job would just be red and the PR couldn't be merged. We could make the job optional, but we don't yet have a good mechanism for finding out about failures from optional jobs (that can be added later though).

CC @rust-lang/libs @obi1kenobi

r? @jieyouxu (for bootstrap and CI stuff)

[rustbot]

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

Warning

If you are changing how CI LLVM is built or linked, make sure to bump
src/bootstrap/download-ci-llvm-stamp.

cc @jieyouxu

This PR modifies bootstrap.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

[Kobzol]

@bors try jobs=x86_64-gnu-stdlib-semver-check

[rust-bors]

💔 Test for 79f5ace failed: CI. Failed job:

• try - x86_64-gnu-stdlib-semver-check (web logs, enhanced plaintext logs)

[Kobzol]

@bors try jobs=x86_64-gnu-stdlib-semver-check

[rust-bors]

☀️ Try build successful (CI)
Build commit: cf27501 (cf2750129ae79b5df875523f88c46d6fe8a84b4c)
Base parent: 922325b (922325bb13bfea5b41454318563f2a65e83c2336)

[Urgau]

I expect quite a few semver breaking changes over the development of nightly features, how are contributors supposed to bypass the CI for changes that are okay? What about stable feature where the breakage is accepted?

[Kobzol]

That's a very good question, that I don't yet know the answer to :) In terms of implementation, we could have some file in the standard library subtree (something like the LLVM bootstrap stamp files) that could be manually bumped in PRs that expect a breaking change. And for those PRs the test would just be green.

[cuviper]

A file-based bypass sounds good to me.

[obi1kenobi]

Just a note that I don't expect CI to be red over development of nightly features. cargo-semver-checks is now aware of stability (including special cases like const-stability) and will not consider those cases SemVer-breaking.

If it would be useful to have a separate report that also considers unstable features' breakage, that's easy enough to add as well (just remove a flag from the invocation) but probably beyond the scope of this PR.

[jieyouxu]

Remark: also thinking about the failure handling

View changes since the review