Fix non-deterministic proc-macro output by replacing HashSet with Ind…

[capickett]

Goal

Meta uses remote execution / distributed builds for rust code (using buck2). This makes our builds susceptible to cache invalidation & build consistency issues. We found that ts-rs proc-macros were generated non-deterministic token streams due to the use of HashSet/HashMap unordered containers.

HashSet iteration order depends on RandomState, which is seeded randomly per process. This caused visit_dependencies statements and where-clause predicates to be emitted in different orders across rustc invocations, breaking build caching and reproducibility.

I discovered this issue internally with buck, but a repro can be made by writing a test like so:

use ts_rs::{Config, TS};

#[derive(TS)]
struct DeterministicMultiGeneric<A, B, C> {
    a: A,
    b: B,
    c: C,
    nested: Vec<A>,
}

/// Run this test many times (it will always pass in a single process since the
/// hash seed is fixed per process)
#[test]
fn deterministic_decl_output() {
    let cfg = Config::from_env();
    assert_eq!(
        DeterministicMultiGeneric::<(), (), ()>::decl(&cfg),
        "type DeterministicMultiGeneric<A, B, C> = { a: A, b: B, c: C, nested: Array<A>, };"
    );
}

#[derive(TS)]
enum DeterministicEnum<X, Y> {
    First(X),
    Second(Y),
    Both { x: X, y: Y },
}

#[test]
fn deterministic_enum_decl_output() {
    let cfg = Config::from_env();
    assert_eq!(
        DeterministicEnum::<(), ()>::decl(&cfg),
        r#"type DeterministicEnum<X, Y> = { "First": X } | { "Second": Y } | { "Both": { x: X, y: Y, } };"#
    );
}

Run this test enough times and it will fail without this PR.

Changes

Replace HashSet with IndexSet (from indexmap) in deps.rs and lib.rs to preserve insertion order. Alternatively, we could define a specific ordering with Ord and use BTreeSet/BTreeMap, etc. This is the minimal change to fix my issue, however I did notice there are a few more instances of HashMap/HashSet in the proc macro layer. Pending agreement on the approach, I could extend the PR to cover those case.

Checklist

• I have followed the steps listed in the Contributing guide.
• If necessary, I have added documentation related to the changes made.
• [*] I have added or updated the tests related to the changes made.

I didn't commit the test here, namely because the test is not reliable; it requires multiple runs to find the breakage, making pinning inconsistent. This could cause unwarranted noise on unrelated PRs in case a breakage does make its way back into the codebase. Open to feedback here.

[gustavo-shigueo]

Hey @capickett, thanks for the PR! Just to confirm, what exactly was non-deterministic? The order of the generics?