2024-02-28
本文由 ChatGPT(gpt-4-1106-preview) 翻譯。
大家好,欢迎阅读又一期的本周 Rust 语言! Rust 是一种编程语言,它赋能每个人构建可靠且高效的软件。 这是其进展和社区动态的每周总结。 想要在本周看到某些内容?请在 Twitter 上通过 @ThisWeekInRust 标记我们,或在 mastodon.social 上通过 @ThisWeekinRust 联系我们,或者发送一个拉取请求给我们。 想要参与进来?我们热爱贡献。
本周 Rust 语言 是在 GitHub 上公开开发的,存档可在 this-week-in-rust.org 查看。 如果您发现本周的期刊中有任何错误,请提交一个 PR。
[HEB][視頻] Rust 課程
[視頻] Rust 中生命周期的初步瞻仰
本週的 crate 是 web-audio-api-rs,這是一個 Rust 實作的 Web Audio API,用於在瀏覽器外部使用。
感謝 Otto Rottier 自我推薦!
一個重要的步驟,對於 RFC 實作來說,就是讓人們試用該實作並給予回饋,特別是在穩定化之前。以下的 RFCs 若在進一步發展之前可以受益於使用者測試:
如果你是特性實現者,並希望你的 RFC 出現在上述清單中,請為你的 RFC 加上新的 call-for-testing 標籤,以及發表評論提供測試指南和/或指導哪一個方面的特性需要測試。
在上週合併了 430 個拉取請求
#[rustc_no_mir_inline]NamePrivacyVisitor 中缺少 adt_defonly_local,減少在貨櫃中編碼屬性struct 出現在 enum 變體中冰冻Rocket 時的恐慌mir::ConstValuemin_exhaustive_patterns 標記為完成TestCase enum 來替換大多數對 PatKind 的匹配assemble_alias_bound_candidates 中不需要 validate_alias_bound_self_from_param_envint::MIN / -1#[attr] expr 上適當發出 expected ;rustc_confusables 標註提供建議core::convert::num 中重構特徵實現<&T as Clone>::clone(x) 因為 T: Clone,建議 #[derive(Clone)]MIRI_SEED_END 來控制種子範圍的結束br 而不是條件式cfg_target_abisimd_insert, simd_extract 指標為常數Barrier::new() 為常數函式MappedMutexGuard, MappedRwLockReadGuard, 和 MappedRwLockWriteGuardBox 分配器上無用的 'static 界限waker_ref 添加 'static 界限CARGO_TERM_COLORtarget.<triple>.rustdocflagsbox_default: 保留所需的路徑段read_line_without_trim: 檢測字符串字面值比較和 .ends_with() 調用unnecessary_clippy_cfg lintmultiple_bound_locations lintunnecessary_get_then_check lintunused_imports 和 unused_import_braces 在 use 上infinite_loopredundant_guards 中考慮 constnessunused_unit: 小心帶有屬性的表達式empty docsunnecessary_to_owned 以處理 Borrow 特徵cast_sign_loss 中的符號處理錯誤和假陰性useless_vec 中的建議錯誤no_effect_underscore_binding 在忽略參數的異步函數中激發implied_bounds_in_implsref_as_ptr 中考慮生命期擴充replace_filter_map_next_with_find_map 不應在動態特徵中工作recreate_crate_graph <-> file_line_index 中的死鎖RUSTC_BOOTSTRAP 重新編譯BorrowKind::Unique 合併進 BorrowKind::Mut這是一個罕見的一週,回退帶來的問題超過了改進,使得平均而言,編譯器在近 100 個基準測試中大約慢了半個百分點。有些回退有解決方案在進行中,但有些問題仍然難以捉摸或者是為了解決正確性問題而引入的。
由 @rylev 完成分類。 修訂範圍:5af21304..71ffdf7f
摘要:
| (instructions:u) | 平均值 | 範圍 | 數量 |
|---|---|---|---|
| 回退 ❌ (主要) | 1.0% | [0.2%, 4.4%] | 69 |
| 回退 ❌ (次要) | 1.4% | [0.2%, 4.9%] | 66 |
| 改善 ✅ (主要) | -1.1% | [-3.3%, -0.2%] | 28 |
| 改善 ✅ (次要) | -0.6% | [-1.5%, -0.2%] | 33 |
| 所有 ❌✅ (主要) | 0.4% | [-3.3%, 4.4%] | 97 |
有 4 個回退,6 個改善,5 個混合;其中 2 個在 rollups 中 總計進行了 58 次藝術品比較
Rust 的變更遵循 Rust RFC(徵求意見稿)程序。以下是本週獲批准實施的 RFCs:
每週,團隊會宣布即將作出決定的RFC和關鍵PR進入「最終意見回饋期」。現在就表達您的觀點。
在軟體開發項目中,追踪問題(Issues)與拉取請求(Pull Requests, 簡稱PRs)是非常關鍵的管理過程。下面是一些定義和解釋:
問題(Issues):問題是用於追踪錯誤報告、功能請求、任務分配、大綱草擬等等。這是一種溝通協作的工具,可以幫助團隊追踪和討論項目中的不同點。
拉取請求 (Pull Requests, PRs):當開發者想要貢獻代碼到現有項目中時,他們會創建一個拉取請求。這是一個告知他人「我已準備就緒,請審查我的代碼」的方式。這個請求會包含一個代碼和文件的比較,顯示出作者所做的變更。
以下是關於追踪問題和PRs的一些常見做法:
使用標籤 (Labels):在問題和PRs中用標籤來分類。像是「bug」、「enhancement」、或「help wanted」這樣的標籤可以增加項目透明度並幫助排序和分配任務。
更新與溝通:對於問題和PRs,維持良好的溝通是關鍵。回應社群的疑問,提供反饋給貢獻者,並且持續地更新PR的狀態都是很重要的。
代碼審查 (Code Reviews):PRs應該通過一個或多個有經驗的開發者的代碼審查。這有助於確保代碼符合質量標準並且與項目目標一致。
自動化測試:自動化測試可以在PRs被合併前驗證代碼變更是否不會破壞現有功能。這種持續整合(CI)的做法可以幫助維持高代碼質量。
文檔更新:當新功能被添加或者現有功能被改變時,相關的文檔也應該更新,以確保它們反映了最新的項目狀態。
這些做法不僅有助於維持項目的結構和順暢運行,而且也鼓勵外部開發者參與和貢獻。對於使用Rust這種社群導向的語言開發的項目來說,這些做法尤其重要,因為它強調社群貢獻和項目的開源性質。
NonZeroINVALID_DOC_ATTRIBUTES lint 預設拒絕confstr(_CS_DARWIN_USER_TEMP_DIR, ...) 作為 TMPDIR 的後備選項2024 年 2 月 28 日至 2024 年 3 月 27 日間的 Rusty 活動 🦀
如果您正在舉辦 Rust 活動,請將其添加到日曆中以在此處提及它。請記得添加活動的鏈接。 有關訪問權限,請通過電子郵件聯繫Rust 社區團隊。
請參閱最新的 r/rust 的徵聘貼文
那將需要 18 百萬兆位元組的 RAM。你沒有那麼多記憶體。
– Alice Ryhl 回答「最大陣列尺寸為何」於 rust-users 上
感謝 Zeroexcuses 的建議!
本週 Rust 由以下編輯:nellshamrell、llogiq、cdmistman、ericseppanen、extrawurst、andrewpollack、U007D、kolharsam、joelmarcey、mariannegoldin、bennyvasquez。
電子郵件列表主辦由 The Rust Foundation 贊助。