Closed: #3903

Example:

mod a {
    pub const POLY_SUBPIXEL_SHIFT: u32 = 8;
    pub const POLY_SUBPIXEL_SCALE: u32 = (1 << POLY_SUBPIXEL_SHIFT) - 1;
    pub fn lerp_u8() {}
    pub fn prelerp_u8() {}
}

pub mod my_module {
    pub struct HashMap;
    pub const POLY_SUBPIXEL_SCALE: i32 = 256;
}

use a::{POLY_SUBPIXEL_SHIFT, lerp_u8};

fn main() {
    println!("SCALE= {}", POLY_SUBPIXEL_SCALE);
    prelerp_u8();
    let value = POLY_SUBPIXEL_SCALE;
}

             Before               |           After             

Why choose reordering over adjusting the push order of CodeActions from the backend/frontend?

Initially, following the guidance in #3903, I attempted to adjust the push order in the backend but found it ineffective.

Then I tried reordering them after the push was complete, and noticed the final presentation seemed to be sorted in segments. For example, we could make Qualify rank higher than Import, but it could never surpass similar name.

I realized this was likely a frontend issue, and eventually located the relevant code here:

I'm not very familiar with TS; the subsequent work relied heavily on Sonnet 4.5 : )

Based on the inserted logs, the issue is indeed determined by the frontend.
However, judging from the code logic, it doesn't seem possible to change the final presentation order by altering the processing sequence, so I decided to sort them after all processing was complete.

The order is based on matklad's idea, namely ra diagnostic > ra assist > rustc diagnostic

As for the criteria for determining priority, it might not be perfectly precise, but it works :)

The frontend testing framework seems relatively basic; I'm not sure where to write tests or how to write them.