[cfg_match] Library edition

[c410-f3r]

#115585

Starts the usage of the cfg_match macro in the standard library.

[rustbot]

r? @Noratrieb

rustbot has assigned @Noratrieb.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[c410-f3r]

r? T-libs

[tgross35]

For reference, beta branch is in two weeks, at which point the complexity with bootstrap wouldn't be needed.

[ChrisDenton]

Yes, I think we should wait at least until then. Though I'm also concerned that cfg_match is still undergoing changes which could cause more churn in the future. I think we should shy away from using unstable features in std until it's nearing stabilization because of the added complexity of doing so.

[jhpratt]

I'm inclined to wait until after bootstrap as well. I don't know the status of cfg_match well enough to make a statement on that. I'll defer to whoever wants to make that decision; feel free to claim the PR for yourself. If no one does post-bootstrap, I'll simply reassign.

[c410-f3r]

#116342 was closed due to the possibility of future modifications but now with #133720 no further breaking changes are expected.

Moreover, the internal use of this feature is intended to assert the robustness of the implementation to ensure a smooth stabilization process, which has always been the case with a multitude of other unstable features.

[ChrisDenton]

Experimenting with new features in the compiler is indeed very much encouraged! But less so for std. Indeed there's an effort to reduce the nightly features std uses. E.g. #94970 and #94971

Personally I'm ok with some experimentation but I would prefer that changes bake in nightly for a bit before risking churn in std.

[bors]

☔ The latest upstream changes (presumably #136533) made this pull request unmergeable. Please resolve the merge conflicts.