El desarrollador Parsa, autor de un blog técnico sobre compiladores y parsers, relata una sesión de refactorización de su motor de JavaScript escrito en Rust en la que una versión 'estética' de una función del lexer provocaba errores de parseo, mientras que una variante menos elegante funcionaba correctamente. La diferencia entre ambas radicaba en sumar a un contador el resultado booleano convertido a entero sin signo mediante x as u32, frente a usar if x { 1 } else { 0 }.
El código ensamblador generado por rustc con optimización máxima muestra que, en la versión con as u32, la comparación y el incremento del contador se realizaban con instrucciones que producen un valor distinto de 0 o 1: concretamente, setne rellena el byte con 0x01 o 0x00, pero luego el add posterior no respetaba esa restricción cuando el valor se propagaba, lo que terminaba corrompiendo el estado interno del lexer en operaciones posteriores como el parseo de un bucle for.
El caso se documentó en el repositorio oficial de Rust (issue #158206) como un fallo del optimizador LLVM: en ciertas combinaciones de operaciones a nivel de bits, la conversión bool as u32 puede optimizarse a un patrón que ya no respeta el rango {0,1}. Parsa recomienda, mientras se corrige, evitar conversiones implícitas en lógica crítica de contadores y preferir condicionales explícitos o máscaras que conserven la garantía binaria del booleano.