未验证 提交 7c23ff27 编写于 作者: E Eric Huss 提交者: GitHub

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``
......@@ -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::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();
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册