Rollup merge of #89098 - GuillaumeGomez:where-bounds-order, r=camelid

Fix generics where bounds order

Fixes #88809.

Like said on the above issue, the issue is that we were expecting `Symbol` comparisons to be string-based but they are integer-based (because `Symbol` is an integer), messing up the bounds order. To fix it, I simply stored into a `FxIndexMap` instead.

r? ``@jyn514``

src/librustdoc/clean/simplify.rs

@@ -11,8 +11,7 @@
 //! This module attempts to reconstruct the original where and/or parameter
 //! bounds by special casing scenarios such as these. Fun!
 
-use std::collections::BTreeMap;
-
+use rustc_data_structures::fx::FxIndexMap;
 use rustc_hir::def_id::DefId;
 use rustc_middle::ty;
 use rustc_span::Symbol;
@@ -23,8 +22,11 @@ use crate::clean::WherePredicate as WP;
 use crate::core::DocContext;
 
 crate fn where_clauses(cx: &DocContext<'_>, clauses: Vec<WP>) -> Vec<WP> {
-    // First, partition the where clause into its separate components
-    let mut params: BTreeMap<_, (Vec<_>, Vec<_>)> = BTreeMap::new();
+    // First, partition the where clause into its separate components.
+    //
+    // We use `FxIndexMap` so that the insertion order is preserved to prevent messing up to
+    // the order of the generated bounds.
+    let mut params: FxIndexMap<Symbol, (Vec<_>, Vec<_>)> = FxIndexMap::default();
     let mut lifetimes = Vec::new();
     let mut equalities = Vec::new();
     let mut tybounds = Vec::new();