Rust 1.97 نام نمادها را به مرز تازه‌ای برای ابزارها تبدیل می‌کند

Rust 1.97.0 لایه‌ای را تغییر می‌دهد که بیشتر توسعه‌دهندگان برنامه به‌ندرت آن را می‌بینند: نام‌هایی که کامپایلر در فایل‌های شیء و باینری‌ها تولید می‌کند. این نسخه، طرح نام‌گذاری نمادهای v0 را در کانال پایدار به پیش‌فرض تبدیل کرده و جایگزین طرح قدیمی‌ای می‌شود که از قراردادهای مرتبط با ABI ایتانیوم C++ استفاده می‌کرد. Rust 1.97.1 که یک هفته بعد منتشر شد، نسخه‌ای جداگانه برای رفع یک خطای کامپایل نادر مرتبط با LLVM است؛ تغییر قالب نمادها به Rust 1.97.0 مربوط می‌شود.

چرا نام نمادها مهم‌اند؟

کامپایلر معمولاً نمی‌تواند یک تابع را فقط با نام سطح‌بالای کد منبع در باینری قرار دهد. نمونه‌سازی‌های جنریک، پیاده‌سازی‌های trait، closureها، ماژول‌ها و چندین crate ممکن است نام‌هایی تولید کنند که در غیر این صورت با هم تداخل داشته باشند. نام‌گذاری نمادها اطلاعات کافی را رمزگذاری می‌کند تا linker بتواند این موارد را از یکدیگر تشخیص دهد.

قالب v0 برای مدل نوع‌ها و ماژول‌های خود Rust طراحی شده است. تیم Rust می‌گوید نمونه‌سازی پارامترهای جنریک در آن مقدار خود را حفظ می‌کند و فقط پشت یک hash پنهان نمی‌شود؛ همچنین قالب به‌اندازه‌ای برگشت‌پذیر است که ابزارها بتوانند نام‌های خواناتری تولید کنند. این طرح از پیشوند اختصاصی _R استفاده می‌کند و نمادهای معمولی را به مجموعه‌ای سازگارتر با پلتفرم‌های مختلف محدود می‌سازد.

در نتیجه، این تغییر برای ابزارهای نزدیک به لایه باینری اهمیت ویژه‌ای دارد: پروفایلرها، گزارشگرهای crash، دیباگرها، تحلیلگرهای باینری، ابزارهای پوشش کد و سیستم‌های ساختی که نمادها را بررسی می‌کنند، اکنون ممکن است در toolchain پایدار با نام‌های v0 روبه‌رو شوند.

داستان اصلی، مهاجرت ابزارهاست

تیم کامپایلر Rust قالب v0 را به‌صورت تدریجی معرفی کرد. یک پیشنهاد پذیرفته‌شده در تیم کامپایلر در سال 2025، پیش‌فرض شدن آن در nightly را راهی برای آشکار کردن مشکلات سازگاری می‌دانست، در حالی که در دوره گذار امکان بازگشت وجود داشت. Rust 1.97.0 این انتقال را برای کاربران stable تکمیل می‌کند؛ قالب قدیمی فقط در nightly قابل فعال‌سازی است.

برای بیشتر توسعه‌دهندگان، اقدام عملی این نیست که نام نمادها را دستی ویرایش کنند. باید ابزارهای اطراف فرایند ساخت را بررسی کنند: دیباگرها، پروفایلرها، symbol serverها، خط لوله‌های پردازش crash و هر کد سفارشی برای demangle کردن. اگر ابزاری نام‌هایی را نشان می‌دهد که با _R آغاز می‌شوند، باید پشتیبانی آن از demangler مربوط به Rust بررسی شود، نه اینکه تصور کنیم باینری خراب شده است.

مستندات rustc، v0 را قالبی مشخص برای تولید خروجی demangle‌شده و خوانا معرفی می‌کند، نه وعده‌ای درباره ABI. ملاحظه: v0 یک ABI پایدار برای Rust نیست؛ بنابراین باینری‌ها و مرزهای FFI نباید نام‌های mangled را قرارداد سازگاری بلندمدت بدانند. رابط‌های عمومی C همچنان باید از توابع صریح extern "C" و نام‌های export‌شده مشخص، مانند نام‌هایی که در صورت نیاز با #[export_name] تعیین می‌شوند، استفاده کنند.

توسعه‌دهندگان ICP چه چیزی را باید زیر نظر بگیرند؟

سرویس‌های Rust و ابزارهای canister که به stack traceهای معمولی Rust وابسته‌اند، پس از پشتیبانی ابزارهای تحلیل از v0 ممکن است بازیابی بهتری داشته باشند. این موضوع می‌تواند فاصله میان یک آدرس تولیدی و تابع جنریک یا پیاده‌سازی trait مربوط به آن را کوتاه‌تر کند. با این حال، نتیجه به کل زنجیره observability وابسته است: کامپایلر، linker، محل ذخیره نمادها، demangler و لایه نمایش همگی باید نام‌ها را به‌درستی حفظ و decode کنند.

راه‌اندازی ایمن این است که toolchain و مجموعه ابزارهای observability را هم‌زمان ارتقا دهید و سپس traceهای symbolized را از چند build واقعی و نماینده با یکدیگر مقایسه کنید. به‌ویژه به automation انتشار توجه کنید؛ ممکن است این فرایند نمادها را حذف کند، جداگانه بایگانی کند یا بر فرض‌های مخصوص نام‌گذاری C++ تکیه داشته باشد. بنابراین این release کمتر درباره تغییر کد منبع Rust است و بیشتر درباره آن است که ابزارهای باینری بتوانند چیزی را بفهمند که Rust مدت‌هاست تولید می‌کند.

منابع: اعلامیه انتشار Rust 1.97.0 و پیشنهاد پذیرفته‌شده تیم کامپایلر Rust درباره پیش‌فرض شدن نام‌گذاری v0.