Формат: Новость
Коротко
Команда Rust предупредила о скором изменении для WebAssembly-таргетов, которое может затронуть существующие проекты. Речь о снятии флага —allow-undefined при линковке через wasm-ld — это должно улучшить диагностику ошибок, но в отдельных случаях способно выявить проблемы в сборке.

Ключевые тезисы
- Во всех WebAssembly-таргетах Rust долгое время использовался флаг —allow-undefined для wasm-ld.
- Флаг убирают в рамках изменения rust-lang/rust#149868; оно скоро появится в nightly и выйдет в Rust 1.96 28 мая 2026 года.
- Главный риск — ошибки конфигурации и сборки могут раньше приводить к некорректным WebAssembly-модулям вместо явной ошибки линковки.
- Разработчики Rust хотят, чтобы поведение WebAssembly было ближе к нативным платформам, где неопределённые символы считаются ошибкой по умолчанию.
- По мнению команды, чаще всего это не сломает проекты, а лишь сделает сообщения об ошибках понятнее.
Детали
Это перевод материала с английского языка.
Команда Rust предупредила, что для WebAssembly-таргетов языка скоро изменится поведение линковщика, и это может повлиять на существующие проекты. В официальном блоге Rust от 4 апреля говорится, что во всех WebAssembly-таргетах исторически использовался флаг —allow-undefined для wasm-ld, но теперь от него планируют отказаться.
Удаление —allow-undefined для wasm-таргетов реализуется в изменении rust-lang/rust#149868. Ожидается, что оно скоро попадёт в nightly-сборки, а затем выйдет в составе Rust 1.96 28 мая 2026 года. В блоге поясняется, что все WebAssembly-бинарники в Rust собираются через wasm-ld, который выполняет роль, аналогичную ld, lld и mold.
С момента появления поддержки WebAssembly в Rust флаг —allow-undefined передавался wasm-ld по умолчанию. Однако это создавало различия между WebAssembly и другими платформами: на нативных платформах неопределённые символы считаются ошибкой по умолчанию.
Почему меняют поведение
По мнению команды Rust, главный риск здесь в том, что из-за ошибок конфигурации или сборки можно получить битый WebAssembly-модуль вместо понятной ошибки компоновщика. В блоге приводятся такие примеры:
- если вместо mylibrary_init по ошибке написали mylibraryinit, финальный бинарник импортирует символ mylibraryinit, а не вызовет связанный C-символ mylibrary_init;
- если mylibrary случайно не был скомпилирован и подключён к итоговому приложению, символ mylibrary_init окажется импортированным вместо ошибки о неопределённом символе;
- если для обработки модуля используются внешние инструменты, например wasm-bindgen или wasm-tools component new, сообщение об ошибке может быть неочевидно связано с исходным кодом;
- ошибки вида Uncaught TypeError: Failed to resolve module specifier «env»… могут означать, что «env» попал в итоговый модуль неожиданно, а настоящая причина — неопределённый символ.
Разработчики подчёркивают, что цель изменения — убрать неожиданное поведение и сделать WebAssembly более похожим на нативные платформы. В теории, по их оценке, ломаться должно немногое: если итоговый WebAssembly-бинарник импортирует неожиданные символы, он, скорее всего, всё равно не запустится в нужной среде, потому что та не предоставляет соответствующие определения. Поэтому чаще всего изменения не будут ломать пользователей, а лишь дадут более полезные диагностические сообщения.
Оригинал: Rust team warns of WebAssembly change