discover_variants sorts by StringId handle, so the build-dir hint lists variants in readdir order

[typeless]

Summary

discover_variants builds a Vec<StringId> of variant directory names and finishes with std::sort(result.begin(), result.end()) (src/core/layout.cpp:221). StringId is enum class StringId : std::uint32_t, so that sorts by interning handle, not by name. The names are interned in read_directory order, i.e. raw readdir order, so the sort reads as a canonicalization and is not one.

This is the same defect as #171 (fixed in #174), at a second site.

Where it shows

The only consumer is the build-directory hint (src/cli/multi_variant.cpp:124-133):

Error: no build directory specified; found: build-arm, build-x86, build-debug

The listing order is a function of filesystem enumeration, so the same tree prints its candidates in a different order on a different machine — or after the directories are recreated in a different order on the same one.

Severity

Cosmetic. Unlike #171, this order never reaches %f, command identity, or anything persisted — discover_variants has exactly one call site and its result is only concatenated into an error message.

Fix

Sort by the interned string, as #174 did for glob_expand:

std::ranges::sort(result, {}, [&pool](StringId id) { return pool.get(id); });

src/cli/cmd_show.cpp:173 and src/cli/multi_variant.cpp:76 already use that form. The remaining std::sort calls over StringId (in cmd_build.cpp, context.cpp, scheduler.cpp, and glob_expand_all's exclusion list) are sort+unique / binary_search set structures, where handle order is order-agnostic by construction — those are correct as written.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TLob4Ef3qyMd3Dnp9q3XmA