rustdoc: deterministic sorting for doc_cfg badges

[shivendra02467]

Fixes #156391

Currently, target-exclusive doc_cfg badges (eg. "Available on...") reuse the order of predicates as they appear in the source code. This often buries popular targets behind niche ones and leads to inconsistent UI rendering.

This PR introduces a deterministic sorting mechanism to the Cfg AST prior to HTML/JSON rendering.

Note for Reviewers:
To provide the best UX, I implemented a lightweight tiering heuristic (prioritizing major platforms like Linux/Apple/Windows first, followed by mobile, then BSDs, and alphabetizing the rest). However, I am completely open to tweaking these priority groupings or falling back to a different sorting logic if the team prefers. Let me know what you think!

[rustbot]

r? @fmease

rustbot has assigned @fmease.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: rustdoc
• rustdoc expanded to 9 candidates
• Random selection from GuillaumeGomez, fmease, lolbinarycat, notriddle

[rustbot]

Some changes occurred in GUI tests.

cc @GuillaumeGomez

[GuillaumeGomez]

Sorting the doc_cfg badges sounds like a good idea, but I'm not sure sorting by "importance" is a good idea. I think we should sort by target then by feature and internally alphabetically.

As for not()/all()/any(), not too sure...

[GuillaumeGomez]

Also, would be nice to have a unit test with different scenarios directly in cfg.rs.

[shivendra02467]

Sorting the doc_cfg badges sounds like a good idea, but I'm not sure sorting by "importance" is a good idea. I think we should sort by target then by feature and internally alphabetically.

@GuillaumeGomez Thanks for the review! That makes complete sense.

I've just pushed a commit that drops the importance heuristic and replaces it with the logic you suggested.

Updates:

1. Sorting Order: It now categorizes by Targets (0) -> Target Features (1) -> Crate Features (2). Within those categories, it falls back to case-insensitive alphabetical sorting.
2. Unit Tests: Added test_sort_for_rendering in cfg/tests.rs to assert this exact categorization and alphabetical fallback, and moved the HTML regression test into the doc-cfg/ directory.

As for not()/all()/any(), not too sure...

I completely agree these are tricky! Here is how this commit handles them:

• It recursively sorts their internal contents using the exact same target -> feature -> alphabetical rules.
• It places the any/all/not blocks themselves into a final Category (3). This effectively pushes complex, nested groupings to the end of the badge list, keeping the simple, single-item targets and features grouped neatly at the front (e.g., it will render unix and (linux or windows) rather than (linux or windows) and unix).

Does pushing the complex nested blocks to the end seem like the best UX call to you, or would you prefer them sorted differently?

[GuillaumeGomez]

Does pushing the complex nested blocks to the end seem like the best UX call to you, or would you prefer them sorted differently?

Sounds like the right way to handle them indeed. Good call!