Update rustc-hash to version 2

[Noratrieb]

This brings in the new optimized algorithm that was shown to have small performance benefits for rustc. I haven't run the rust-analyzer benchmarks.

See rust-lang/rustc-hash#37.

[Noratrieb]

oh lord, it looks like something relies on the iteration order or something like that :3.

[Veykril]

Yup, the iteration here calls a mutating callback and the state there seems to be iteration dependent (sorting the iterator by key causes the same issue on master)

rust-analyzer/crates/hir-ty/src/lib.rs

Line 249 in 1271dff

cm.memory.iter().map(|(addr, val)| transform((addr, val))).collect()

[Veykril]

The funny thing is, that test apparently should succeed given rustc is fine with it?

        pub enum TagTree {
            Leaf,
            Choice(&'static [TagTree]),
        }
        const GOAL: TagTree = {
            const TAG_TREE: TagTree = TagTree::Choice(&[
                {
                    const VARIANT_TAG_TREE: TagTree = TagTree::Choice(
                        &[
                            TagTree::Leaf,
                        ],
                    );
                    VARIANT_TAG_TREE
                },
            ]);
            TAG_TREE
        };
        ```
        compiles just fine, yet the test errors on master

[Veykril]

Naively I'd say, lets replace the FxHashMap at

rust-analyzer/crates/hir-ty/src/lib.rs

Line 199 in 191949e

vtable: VTableMap,

with an FxIndexMap and change the expected test output to success (if that change makes it succeed)

[HKalbasi]

The test looks strange. I guess it meant to do recursive constants, something like this:

pub enum TagTree {
    Leaf,
    Choice(&'static [TagTree]),
}
const GOAL: TagTree = {
    const TAG_TREE: TagTree = TagTree::Choice(&[
        {
            const VARIANT_TAG_TREE: TagTree = TagTree::Choice(
                &[
                    TAG_TREE,
                ],
            );
            VARIANT_TAG_TREE
        },
    ]);
    TAG_TREE
};

The failure of the original test clearly is a bug. It should work with any order of execution, and sorting or using an stable iteration order does not fix the underlying problem. I would suggest changing the test to use an actual recursive constant like the code above, and opening an issue for that bug for further investigation.

[Veykril]

@bors r+

[bors]

📌 Commit 6a78851 has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit 6a78851 with merge aee8b45...

[bors]

💔 Test failed - checks-actions

[bors]

☔ The latest upstream changes (presumably #18151) made this pull request unmergeable. Please resolve the merge conflicts.

[Veykril]

Okay let's see what breaks
@bors r+

[bors]

📌 Commit 8be3b80 has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit 8be3b80 with merge 102a3b1...

[bors]

💔 Test failed - checks-actions

[Veykril]

@bors r+

[bors]

📌 Commit 02e189d has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit 02e189d with merge fb832ff...

[bors]

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing fb832ff to master...

[Noratrieb]

nice!