Rust Edition Diam-Diam Ubah Arti Kode: Yang Tak Bisa Di-fix cargo fix

⚡ Jawaban Singkat / Key Takeaways

Semantic breaking changes antar Rust edition tidak terdeteksi oleh cargo fix, karena kode tetap compile tanpa error, hanya artinya yang bergeser secara diam-diam. Masalah paling rawan terjadi di tiga area: dyn inference yang berubah, closure capture rules yang melebar, dan trait resolution yang ganti prioritas. Tanpa audit manual, bug ini bisa lolos ke production dan bertahan berbulan-bulan sebelum terdeteksi.

Bayangkan ini: kamu maintainer workspace 50 crate. Rust 1.85 rilis dan semua hype soal edition 2024. Kamu upgrade, jalankan cargo fix --edition, lihat output bersih, merge ke main. CI hijau. Production stabil. Tiga bulan kemudian, bug aneh muncul: sistem rekomendasi tiba-tiba memberikan hasil berbeda untuk input yang sama. Kamu git bisect, trace log, debug sampai jam 2 pagi. Akhirnya kamu temukan source-nya: closure di crate parser-mu meng-capture variable yang sebelumnya tidak di-capture. Kompilasi berhasil. Tidak ada error. Tidak ada warning. Cuma arti yang berubah.

Ini bukan skenario teoritis. Ini realita yang sudah terjadi di ekosistem crate besar seperti serde, syn, dan tokio saat transisi dari edition 2018 ke 2021. Dan dengan edition 2024 yang membawa perubahan lebih dalam di trait solver, polanya akan berulang, hanya lebih sulit dideteksi.

Apa yang Bisa dan Tidak Bisa Diperbaiki cargo fix

Banyak Rust developer salah paham soal cargo fix. Mereka kira tool ini bisa menyelesaikan semua masalah migrasi edition. Faktanya, cargo fix hanya menangani syntactic breaking changes: syntax yang jadi invalid, keyword baru yang bentrok, atau aturan borrow checker yang berubah.

Semantic changes tidak pernah disentuh cargo fix. Perubahan perilaku di mana kode tetap valid tetapi menghasilkan output berbeda atau side effect berbeda, berada di luar jangkauan alat otomatis manapun. Compiler tidak bisa membaca niatmu. Compiler hanya tahu apakah kode valid atau tidak.

• Syntactic breaking (bisa di-fix): keyword baru (gen, raw), unsafe extern requirement, prelude collision
• Semantic breaking (tidak bisa di-fix): perubahan aturan dyn inference, closure capture rules, trait resolution priority

Yang berbahaya adalah yang kedua. Kode-mu compile, test suite-mu mungkin masih hijau (kalau coverage-mu tidak menjangkau edge case ini), dan kamu menganggap semuanya aman. Padahal artinya sudah bergeser.

Jebakan 1: dyn Inference yang Melebar Diam-Diam

Ini jebakan paling underrated dan paling jarang dibahas. Di edition 2018 dan 2021, dyn Trait harus ditulis eksplisit. Kalau kamu menulis Box<Read> tanpa dyn, compiler memberi warning. Di edition 2024, aturan ini diperketat, tetapi perilaku inference di beberapa konteks justru berubah arah sebaliknya: compiler sekarang lebih agresif meng-infer dyn di tempat yang sebelumnya tidak.

// Edition 2021: ini adalah generic parameter
fn process<T: Read>(r: T) { ... }

// Edition 2024: di konteks tertentu, compiler bisa 
// meng-infer ini sebagai dyn tanpa peringatan
fn process(r: impl Read) { ... }

Perhatikan potensi monomorphization difference. Di edition 2021, T: Read dimonomorphize per tipe konkret. Di edition 2024, kalau compiler meng-infer sebagai dyn, kamu tiba-tiba punya vtable dispatch yang tidak ada sebelumnya. Performa turun, dan yang lebih parah, kamu tidak tahu kalau itu terjadi kecuali kamu memeriksa assembly.

Masalah ini sudah dilaporkan di Rust issue tracker dan dibahas di Rust 2024 Edition Guide. Namun belum ada solusi otomatis karena compiler tidak tahu niatmu.

Jebakan 2: Closure Capture Rules yang Melebar

Ini yang paling sering bikin bug lolos ke production. Di edition 2021, closure meng-capture variable berdasarkan apa yang dipakai di body closure. Di edition 2024, rule-nya berubah: closure sekarang bisa meng-capture seluruh struct atau enum meskipun kamu hanya mengakses satu field.

struct Data {
    id: u64,
    payload: Vec<u8>,
}

let data = Data { id: 1, payload: vec![1, 2, 3] };

// Edition 2021: hanya capture data.id (copy)
// Edition 2024: capture seluruh data (move!)
let get_id = || data.id;

// data.payload masih bisa dipakai di 2021
// di 2024: sudah di-move, error kalau diakses

Untungnya, perubahan capture ini seringkali menghasilkan compile error (move after use). Tapi ada kasus di mana ia tidak menghasilkan apa-apa: ketika semua akses ke data adalah copy atau reference. Di situ, closure capture yang berbeda hanya mengubah performa dan lifetime behavior, bukan menghasilkan error. Bug-nya muncul ketika refactoring selanjutnya menyentuh kode yang sama, dan tiba-tiba muncul error yang membingungkan.

Baca juga artikel kami tentang perubahan NLL borrow checker di Rust 1.85 untuk memahami bagaimana perubahan capture rules berinteraksi dengan self-referential patterns.

Jebakan 3: Trait Resolution Priority yang Berubah

Ini yang paling canggih dan paling sulit dideteksi. Trait resolution di Rust menentukan trait mana yang dipanggil ketika beberapa trait menyediakan method dengan nama yang sama. Prioritas ini berubah antar edition, dan perubahannya sangat halus.

use std::fmt::Display;

trait CustomFormat {
    fn format(&self) -> String;
}

struct Value(u64);

impl Display for Value {
    fn fmt(&self, f: &mut Formatter) -> FmtResult {
        write!(f, "Display({})", self.0)
    }
}

impl CustomFormat for Value {
    fn format(&self) -> String {
        format!("Custom({})", self.0)
    }
}

let v = Value(42);
// Edition 2021 vs 2024: trait mana yang dipanggil?
println!("{}", v.format());

Di edition 2021, kompiler mengikuti aturan tertentu. Di edition 2024 dengan next-gen trait solver, priority bisa berbeda. Tidak ada error. Tidak ada warning. Output program berubah diam-diam. Dan ini persis jenis bug yang paling mahal: ditemukan oleh customer, bukan oleh CI.

Referensi lebih dalam soal trait solver bisa dibaca di Inside Rust blog tentang next-gen trait solver dan RFC 2375.

Framework Audit: Deteksi Manual yang Sistematis

Kalau cargo fix tidak bisa membantu, kamu harus punya checklist manual. Berikut framework tiga langkah yang bisa langsung kamu terapkan di codebase:

1. Audit dyn Inference via Grep Pattern

# Cari semua penggunaan trait object tanpa dyn eksplisit
rg 'impl \w+\s*' --type rust -l
rg 'Box<\w+\s*>' --type rust -l | grep -v dyn

# Cari generic parameter yang mungkin ter-infer sebagai dyn
rg 'fn.*<T:\s*\w+\+?\w*>' --type rust -l

Hasil dari grep ini adalah daftar file yang wajib kamu review manual. Fokus pada fungsi yang trait bound-nya adalah trait object-safe (punya method dengan &self).

2. Audit Closure Capture dengan cargo clippy

# Aktifkan lint khusus closure capture
cargo clippy -- -W clippy::redundant_closure_for_method_calls \
    -W clippy::manual_map \
    -W clippy::uninlined_format_args

Clippy tidak bisa mendeteksi perubahan capture yang sudah terjadi. Tapi ia bisa menandai closure yang strukturnya rentan terhadap perubahan capture rule. Closure yang mengakses field spesifik dari struct adalah kandidat utama.

3. Differential Testing: Bandingkan Output Antar Edition

Ini teknik paling ampuh. Jalankan test suite yang sama di dua edition berbeda dan bandingkan hasilnya:

# Build dan test di kedua edition
cargo +stable test --edition 2021 > results-2021.txt
cargo +stable test --edition 2024 > results-2024.txt

# Bandingkan
diff results-2021.txt results-2024.txt

Kalau test suite-mu punya coverage yang baik, diff ini akan menunjukkan setiap perbedaan perilaku. Tapi hati-hati: test yang hanya memeriksa “tidak panic” tidak cukup. Kamu butuh assertion eksplisit terhadap nilai output.

Yang Harus Dilakukan Sebelum Upgrade Edition

• Baca edition guide sampai habis. Jangan cuma lihat daftar breaking changes. Pahami setiap perubahan perilaku yang didokumentasikan. Rust 2024 Edition Guide punya bagian khusus soal semantic changes.
• Jalankan differential testing wajib. Test suite harus dijalankan di kedua edition dan hasilnya dibandingkan.
• Audit manual tiga area rawan di atas. dyn inference, closure capture, trait resolution.
• Jangan upgrade semua crate sekaligus. Lakukan per-crate, mulai dari leaf dependencies. Verifikasi satu per satu.
• Simpan artefak build edition lama. Kalau ada bug di production, kamu bisa binary-diff untuk mencari sumbernya.

Kalau workspace-mu besar dan compile time jadi masalah setelah upgrade, baca artikel kami tentang flag -Zpolymorphize untuk mitigasi di edition 2026. Untuk persiapan upgrade dari edition 2021, cek checklist lengkap Rust 2024 Edition.

FAQ

Apa itu semantic breaking change dalam konteks Rust edition?

Semantic breaking change adalah perubahan aturan compiler yang membuat kode tetap valid secara sintaks, tetapi artinya berbeda. Berbeda dengan syntactic breaking change yang menghasilkan error kompilasi, semantic change diam-diam mengubah perilaku program tanpa peringatan apapun.

Kenapa cargo fix tidak bisa mendeteksi perubahan semantic?

Karena cargo fix bekerja di level syntax tree. Ia bisa mengganti keyword, menambah annotasi, atau mengubah struktur kode yang tidak valid. Tapi ia tidak bisa membaca intent programmer. Kalau compiler menganggap dua versi kode sama-sama valid, cargo fix tidak akan menyentuhnya, meskipun artinya berbeda.

Bagaimana cara paling efektif mendeteksi semantic breaking changes?

Differential testing: jalankan test suite lengkap di dua edition berbeda dan bandingkan hasilnya. Pastikan test-mu punya assertion terhadap nilai konkret, bukan cuma “tidak panic”. Selain itu, audit manual di tiga area rawan: dyn inference, closure capture rules, dan trait resolution priority.

Apakah semua crate harus segera upgrade edition?

Tidak. Edition lama tetap didukung penuh oleh compiler Rust terbaru. Kamu bisa tetap di edition 2021 selama bertahun-tahun tanpa masalah. Upgrade hanya diperlukan kalau kamu butuh fitur eksklusif edition baru atau ingin mengikuti konvensi ekosistem. Yang penting: kalau kamu upgrade, lakukan dengan audit, bukan dengan asumsi bahwa cargo fix sudah menyelesaikan semuanya.

Kesimpulan

cargo fix adalah alat bantu, bukan jaminan keamanan. Setiap Rust edition membawa perubahan semantic yang tidak bisa diotomatisasi, dan tugas auditor, maintainer, serta arsitek untuk menemukannya sebelum bug menyelinap ke production. dyn inference, closure capture rules, dan trait resolution priority adalah tiga area paling rawan. Framework audit tiga langkah di artikel ini bisa langsung kamu terapkan sebelum merge ke main branch.

Jangan biarkan kode yang “compile tanpa error” menipumu. Di balik layar hijau CI, arti kode-mu mungkin sudah berubah. Dan bug yang paling mahal selalu bug yang ditemukan oleh customer, bukan oleh compiler.

Punya pengalaman pahit dengan silent semantic change? Atau nemu jebakan lain yang tidak dibahas di sini? Drop di kolom komentar. Komunitas Rust bergerak dari pengalaman nyata, bukan dari dokumentasi yang rapi.