حل‌کنندهٔ تریت‌های Rust از مرز نایتلی عبور کرد؛ توسعه‌دهندگان پیش از پایدارسازی چه چیزی را آزمایش کنند؟

یکی از بزرگ‌ترین گذارهای کامپایلر Rust در سال‌های اخیر اکنون برای آزمایش عملی در دسترس است. تیم Rust در ۲۱ اوت اعلام کرد که حل‌کنندهٔ نسل جدید تریت‌ها به‌صورت پیش‌فرض در کانال نایتلی فعال می‌شود و پایدارسازی آن برای ماه‌های آینده برنامه‌ریزی شده است.

این حل‌کننده یک جزء داخلی rustc است؛ بنابراین بیشتر برنامه‌ها فوراً یک قابلیت زبانی پایدار جدید دریافت نمی‌کنند. اهمیت آن معماری است: سازوکارهای اصلی مورد استفاده برای اثبات where-clauseها، نرمال‌سازی نوع‌های وابسته و حل روابط تریت‌ها جایگزین می‌شوند. هدف پذیرفته‌شدهٔ پروژه Rust این است که -Znext-solver=globally را پایدار کند، پیاده‌سازی قدیمی را کنار بگذارد و از این پایه برای توسعهٔ آیندهٔ سیستم نوع استفاده کند.

یکی از حوزه‌های قابل مشاهده، impl Trait است. پیاده‌سازی جدید نحوهٔ پردازش impl Trait در جایگاه بازگشت را تغییر می‌دهد و زیرساخت لازم برای قابلیت‌هایی مانند Type Alias Impl Trait و Return Type Notation دانسته می‌شود. این پروژه همچنین انتظار دارد بازطراحی جدید راه را برای اصلاح خطاهای soundness در سیستم نوع و پشتیبانی بهتر از قیود با رتبهٔ بالاتر باز کند.

دلیل عملی برای آزمایش اکنون این است که این تغییر می‌تواند ساخت پروژه‌های موجود را عوض کند. issue رهگیری Rust تغییرات مورد انتظار در استنتاج نوع، حل تریت و متد، تفاوت در محدودیت بازگشت و crateهای تحت تأثیر را ثبت می‌کند. تیم همچنین می‌گوید پیام‌های خطا هنوز به کار بیشتری نیاز دارند. این موارد لزوماً regression نیستند؛ بعضی خطاها رفتاری را اصلاح می‌کنند که حل‌کنندهٔ قدیمی به‌اشتباه می‌پذیرفت، اما همچنان ممکن است نگه‌داران کتابخانه را به اصلاح کد یا ماتریس آزمایش وادار کنند.

رفتار زمان کامپایل نیز به نوع workload بستگی دارد. Rust گزارش می‌دهد که تقریباً همهٔ ۲۰ هزار crate برتر بررسی‌شده، عملکردی عملاً مشابه میان دو حل‌کننده داشته‌اند، در حالی که برخی نقاط پرت قبلی به‌طور چشمگیری بهتر شده‌اند. در اعلامیهٔ رسمی، DataFusion به‌عنوان نمونه‌ای معرفی شده که با حل‌کنندهٔ جدید بیش از هشت برابر سریع‌تر کامپایل می‌شود؛ با این حال، هدف پروژه همچنان رسیدن به برابری عملکرد با حل‌کنندهٔ قدیمی است. بنابراین اندازه‌گیری واقعی از فرض یک افزایش سرعت عمومی ارزشمندتر است.

برای تیم‌های Rust، امن‌ترین آزمایش استفاده از CI نایتلی جداگانه است. rustup update nightly را اجرا کنید، workspaceهای نماینده را بسازید و پیام‌های خطا، زمان ساخت، crateهای پر از proc-macro، نوع‌های وابسته با رتبهٔ بالا و قابلیت‌های ناپایدار سیستم نوع را مقایسه کنید. ساخت پایدار را همچنان دروازهٔ انتشار نگه دارید. اگر ساخت نایتلی مشکلی نشان داد، پیش از ایجاد گزارش جدید issue رهگیری کامپایلر را بررسی کنید. در نایتلی می‌توان حل‌کننده را با -Znext-solver=coherence، از طریق RUSTFLAGS یا در .cargo/config.toml غیرفعال کرد.

یک caveat مهم این است که این تغییر هنوز فقط یک آزمایش نایتلی است: تیم Rust وجود شکست‌های غیرجزئی، نقص در پیام‌های خطا و کار باقی‌ماندهٔ عملکردی را مستند کرده است؛ بنابراین توسعه‌دهندگان نباید هنوز آن را قراردادی پایدار برای production بدانند. ارزش این انتشار در پنجرهٔ دریافت بازخورد است؛ پنجره‌ای که به نگه‌داران اجازه می‌دهد لبه‌های واقعی اکوسیستم را پیدا کنند، در حالی که تیم کامپایلر هنوز پیش از پایدارسازی امکان تغییر رفتار را دارد.