External Publication
Visit Post

Compiler should avoid generating very long type name

Rust Internals [Unofficial] March 28, 2026
Source

Rust's "legacy" symbol names already have a hash, and "v0" format supports backreferences, which is a form of compression.

But I'd like the problem to be tackled more at the source. Instead of generating tons of data to process and compress, generate less!

Debuginfo of zero-cost abstractions isn't zero-cost

It's preserved in full fidelity, but it's practically useless when the code for it compiles down to a single instruction or nothing. It's supposed to help debugging, but it has a net-negative value for debugging- it's tedious to jump into multiple layers of tiny wrapper functions, like < going through PartialOrd trait. Sometimes std uses specialization traits, which adds a ton of abstract indirect boilerplate in debug info, only to remove the code behind it.

I wish I could just completely discard debuginfo for all inlineable code. Having that debuginfo is worse than not having it.

The overly detailed excessively inlined debuginfo also destroys code attribution in godbolt. Almost every line technically is from core, and godbolt isn't showing which lines of code I wrote compiled to. I was shocked when I compared that to C++ which doesn't attribute stl templates to its standard library, so godbolt has 1:1 mapping between every C++ source code line and its assembly. Rust has maybe 1 in 10 lines working, and they're usually useless ones like function prolog.

Automatically de-genericize code

The most bloated generic code usually has lots of unused parameters. Every method of a type inherits all of its parameters, but not every method uses all of them. When the types are nested (iterators, futures, closures) every needlessly varying generic argument multiplies the cost.

People sometimes fix it by hand by wrapping fragments of code in local functions with fewer (or zero) generic type arguments, but I wish the compiler could do that automatically.

Discussion in the ATmosphere

Loading comments...