Aug 29, 2026, 3:10 PM@adotinthevoid @imperio i think such a post would very quickly turn into "why are there only three rust compilers?" (rustc, RA, cargo-semver-checks)
- Aug 29, 2026, 3:10 PM
Replies
- Aug 29, 2026, 3:11 PM
@adotinthevoid @imperio "you're being unfair to mrustc and RustRover" ok a little bit but like. name res is so stupidly hard in rust
Guillaume Gomezimperio@toot.catAug 29, 2026, 3:58 PM@jyn @adotinthevoid Yes but it allows:
pub struct Y;
const X: usize = {
impl Y {
pub fn foo(&self) {}
}
0
};
fn main() {
impl Y {
fn new() -> Self { Y }
}
fn inner() -> Y {
Y::new()
}
inner().foo();
}So sounds definitely worth it, no? T_T
- Guillaume Gomezimperio@toot.catAug 29, 2026, 3:59 PM
@jyn @adotinthevoid We can also mention reexports and its endless curse. Last iteration on this: when using
--document-private-items, should crate-levelusebe displayed too, or onlypub(crate)ones even though it's implied by default? :') 
ada :ferris:pmmeurcatpics@ieji.deAug 29, 2026, 7:20 PM@jyn @adotinthevoid @imperio probably a naive question but: can't you librarify the nameres algorithm and share it across compilers? Or is it infeasible to separate it from the internal representation? (and if you're wondering: no, I haven't interacted with nameres in r-a yet..)
- Aug 30, 2026, 6:42 AM
@pmmeurcatpics @adotinthevoid @imperio rustc_resolve and rustc_expand are very tightly tied to rustc's internal representation. they output HirIds into an arena, "freeze" them, and once those arenas are full you cannot ever modify them again. so for example things like "suggest extracting a function into a separate module and check that it name resolves after" are simply impossible, you have to completely rerun compilation with a new Session rather than calling back into the library.
in general lots of rustc is like this ... it has so much global state.