網(wǎng)站首頁(yè) 編程語(yǔ)言 正文
+=
運(yùn)算符與 MIR 應(yīng)用
本文
+=
運(yùn)算符部分整理自 Why does += require manual dereference when AddAssign() does not? 后半部分,
MIR 部分是我自己補(bǔ)充的。只在 https://zjp-cn.github.io/rust-note/ 上更新,其他地方懶得同步更新。
+=
解語(yǔ)法糖
一個(gè)基礎(chǔ),但很少會(huì)思考的問題,Rust 的 +=
運(yùn)算符是什么代碼的語(yǔ)法糖?
a = a + b
不等價(jià)于 a += b
a = a + b
是 a += b
的語(yǔ)法糖嗎?這意味著任何 a += b
與任何 a = a + b
代碼等價(jià)。
如果以標(biāo)準(zhǔn)庫(kù)定義的 impls 為例子,你可能覺得兩種寫法都能編譯,而且結(jié)果一致。
但考慮以下自定義類型的實(shí)現(xiàn):
use std::ops::{Add, AddAssign}; fn main() { let mut s = S; s += (); // ok s = s + (); // error: expected struct `S`, found `()` } struct S; impl Add<()> for S { type Output = (); fn add(self, _: ()) { } } impl AddAssign<()> for S { fn add_assign(&mut self, _: ()) { } }
代碼不通過,原因是顯然的,s + ()
的類型是 ()
,無法賦值給 s
—— a = a + b
不是 a += b
的語(yǔ)法糖。
從運(yùn)算符的 trait 定義來看(以 +
vs +=
為例),它們沒有任何關(guān)系:
pub trait Add<Rhs = Self> { type Output; fn add(self, rhs: Rhs) -> Self::Output; } pub trait AddAssign<Rhs = Self> { fn add_assign(&mut self, rhs: Rhs); }
AddAssign::add_assign(&mut a, b)
與 a += b
+
和 +=
是典型的二元運(yùn)算符和復(fù)合賦值運(yùn)算符。根據(jù)各自的運(yùn)算符 trait 定義,可以得到以下解語(yǔ)法糖:
-
a + b
實(shí)際調(diào)用Add::add(a, b)
-
a += b
實(shí)際調(diào)用AddAssign::add_assign(&mut a, b)
注意以下幾點(diǎn):
- 若 a 和 b 擁有所有權(quán)時(shí),其右側(cè)運(yùn)算數(shù) b 的所有權(quán)被獲取1,而對(duì)待左側(cè)運(yùn)算數(shù)所有權(quán)的方式并不相同:
- a + b 獲取了 a 的所有權(quán)(無法再使用 a)
- a += b 獲取了 a 的獨(dú)占引用,而非所有權(quán)(a 必須是 mut 的,而且此后仍可以使用 a)
- 若 a 或 b 不擁有所有權(quán)時(shí),則不存在對(duì) a 或 b 所有權(quán)的轉(zhuǎn)移2:
- 當(dāng) implementor 為引用時(shí),參數(shù)一并沒有發(fā)生所有權(quán)的移動(dòng)
- 當(dāng)泛型類型參數(shù)為引用時(shí),參數(shù)二并沒有發(fā)生所有權(quán)的移動(dòng)
- 調(diào)用的形式最好使用完全限定語(yǔ)法,而不是方法調(diào)用語(yǔ)法。這是因?yàn)榉椒ㄕ{(diào)用表達(dá)式存在隱式的 自動(dòng)引用/解引用,而基于類型的分析才更可靠。
- a + b 實(shí)際調(diào)用 <TypeOfA as Add<TypeOfB>>::add(a, b),優(yōu)于 a.add(b)
- a += b 實(shí)際調(diào)用 <TypeOfA as AddAssign<TypeOfB>>::add_assign(&mut a, b),優(yōu)于 (&mut a).add_assign(b)
本文的重點(diǎn)在于 a += b
,而不是 a + b
,所以對(duì) a + b
的內(nèi)容就此結(jié)束。
對(duì)于分析 a += b
,我遵循以下思考流程:
- 寫下兩側(cè)的類型,
- 如
Self += Rhs
實(shí)際調(diào)用的形式,如 <Self as AddAssign<Rhs>>::add_assign(&mut Self, Rhs)
<Self as AddAssign<Rhs>>::add_assign(&mut a, b)
- 完全限定語(yǔ)法的幾種等價(jià)形式:
-
Self: AddAssign<Rhs>
:這在分析 trait bounds 時(shí)常用 -
impl AddAssign<Rhs> for Self
:這在搜索具體實(shí)現(xiàn)時(shí)有用3
-
但像 +=
這樣的“復(fù)合賦值運(yùn)算符”,一個(gè)鮮為人知的規(guī)則是關(guān)于兩側(cè)運(yùn)算數(shù)的求值順序。
賦值表達(dá)式的求值順序
通過一個(gè)示例來感受求值順序?yàn)槭裁粗匾?/p>
*{ print!("lhs "); &mut 0 } += { print!("rhs "); 0 }; *{ print!("lhs "); &mut String::from("a") } += { print!("rhs "); "b" };
這段代碼打印什么?
如果你能準(zhǔn)確說出和解釋打印的內(nèi)容,那么這小節(jié)內(nèi)容可以跳過了。
如果你不知道答案,請(qǐng)往下看。
規(guī)則
Rust 中,大部分表達(dá)式是從左往右求值的,比如對(duì)于方法調(diào)用表達(dá)式 (method call expression) a.add(b)
,脫糖為Add::add(a, b)
,然后先計(jì)算左邊的 a
,再計(jì)算右邊的 b
。但賦值表達(dá)式不一定是從左到右求值。
Rust 具有兩種“賦值表達(dá)式”:
- 賦值表達(dá)式 (assignment expressions):將一個(gè)值移動(dòng)進(jìn)指定的地方,語(yǔ)法為
assignee operand = assigned value operand
。 - 復(fù)合賦值表達(dá)式 (compound assignment expressions):將運(yùn)算/邏輯二元運(yùn)算符與賦值表達(dá)式結(jié)合起來,語(yǔ)法為
-
assigned operand 操作符 modifying operand
,其中“操作符”為一個(gè)標(biāo)記后跟一個(gè)=
(中間不含空格),比如+=
、|=
、<<=
。
兩側(cè)運(yùn)算數(shù)的名稱非常不直觀,所以我使用左右兩側(cè)的表達(dá)方式來稱呼它們。實(shí)際上,它們以前被稱作“左值” (lvalue) 和“右值” (rvalue)。
對(duì)賦值表達(dá)式來說,先計(jì)算等號(hào)右側(cè)的值,再計(jì)算等號(hào)左側(cè)的值,即從右到左;對(duì)于解構(gòu)賦值,其內(nèi)部求值順序?yàn)閺淖蟮接摇?/p>
# let (mut a, mut b); (a, b) = (3, 4); // 從右到左:先計(jì)算等號(hào)右側(cè)的 (3, 4),再賦值給等號(hào)左側(cè)的 (a, b) // 脫糖為 { let (_a, _b) = (3, 4); // 解構(gòu)賦值過程中,從左到右 a = _a; // 先賦值給解構(gòu)模式左邊的 a b = _b; // 再賦值給解構(gòu)模式右邊的 b }
對(duì)于復(fù)合賦值表達(dá)式,若兩側(cè)的類型同時(shí)為 primitives,從右到左計(jì)算;否則從左到右計(jì)算。
回到本小節(jié)開頭的示例,現(xiàn)在可以仔細(xì)分析代碼了:
// 等號(hào)兩側(cè)的類型都為 `i32`,它是 primitive type,所以從右到左計(jì)算,打印 `rhs lhs ` *{ print!("lhs "); &mut 0 } += { print!("rhs "); 0 }; // 等號(hào)左右的類型為 `String` 和 `&str`,都不是 primitive type,所以從左到右計(jì)算,打印 `lhs rhs ` *{ print!("lhs "); &mut String::from("a") } += { print!("rhs "); "b" };
或許這些細(xì)節(jié)你會(huì)感到困惑:
問 | 答 |
---|---|
等號(hào)左側(cè)為什么要那樣寫? | 因?yàn)椴辉试S直接寫 0 += ... |
為什么左側(cè)可以維持臨時(shí)的引用 &mut ? |
見 temporary-lifetime-extension |
為什么左側(cè)類型是 i32
|
0 的類型為 i32 ,這是 Rust 默認(rèn)推斷的;&mut 0 類型為 &mut i32 ;*&mut 0 類型為 i32
|
為什么 i32 是 primitive type? |
見標(biāo)準(zhǔn)庫(kù) primitive types |
什么是 primitive type? | 見標(biāo)準(zhǔn)庫(kù) primitive types |
為什么 &str 不是 primitive type? |
見標(biāo)準(zhǔn)庫(kù) primitive types,且見下面的例子:i32 是,&i32 不是,所以 str 是,&str 不是 |
總而言之,在 Rust 中,大部分表達(dá)式的求值順序是從左往右的,僅有少數(shù)地方是從右往左的,比如:
賦值表達(dá)式:先計(jì)算等號(hào)右側(cè)復(fù)合賦值表達(dá)式:僅在兩側(cè)運(yùn)算數(shù)都為 primitive types 時(shí)才先計(jì)算右側(cè)運(yùn)算數(shù)。為了鞏固這一條,請(qǐng)確保你完全理解下面的
代碼 和注釋。此外,你還可以看懂 rustc 的這個(gè) 測(cè)試代碼。
use std::num::Wrapping; macro_rules! add_assign { ($e1:expr, $e2:expr) => { *({print!("lhs "); &mut $e1}) += {print!("rhs "); $e2}; println!(""); } } fn main() { add_assign!(1, 2); // rhs lhs: both operands are primitives add_assign!(1, &2); // lhs rhs: Rhs &i32 is not a direct primitive add_assign!(String::new(), ""); // lhs rhs: neither operands are primitives add_assign!(Wrapping(1), Wrapping(2)); // lhs rhs: neither operands are primitives // So usually the execution order of `+=` is LTR (left-to-right) }
MIR
Rust 的 MIR 是 HIR 到 LLVM IR 的中間產(chǎn)物,對(duì) Rust 眾多語(yǔ)法糖進(jìn)行了脫糖,并且極大地精簡(jiǎn)了 Rust
語(yǔ)法(但并非其語(yǔ)法子集),是觀察和分析 Rust 代碼的常用手段,尤其是在控制流圖和借用檢查方面。
獲取 MIR 的最簡(jiǎn)便的方式是通過 playground 左上角下拉框,點(diǎn)擊 MIR 按鈕。
此外,你還可以使用 rustc src/main.rs -Z dump-mir=main
或 cargo rustc -- -Z dump-mir=main
獲得有關(guān) main 函數(shù)完整的 MIR
- 查看
mir_dump/main.main.-------.renumber.0.mir
等文件 - 使用
cargo rustc -- -Z help
查看更多 mir 相關(guān)命令 - 相關(guān) MIR 資料
Rust Blog: Introducing MIR 友好的官方入門解釋
rustc-dev-guide: MIR Debugging
rustc-dev-guide: The MIR (Mid-level IR)
對(duì)于上一節(jié)開頭的示例:
// 去除了無關(guān)和冗雜的 print!,將這段代碼復(fù)制到 play.rust-lang.org 查看 MIR *{ &mut 0 } += 0; *{ &mut String::from("a") } += "b";
關(guān)鍵的 MIR 輸出:
bb0: {
? ? _1 = const 0_i32;
? ? _3 = const 0_i32;
? ? _2 = &mut _3;
? ? _4 = CheckedAdd((*_2), _1);
? ? assert(!move (_4.1: bool), "attempt to compute `{} + {}`, which would overflow", (*_2), move _1) -> bb1;
}bb2: {
? ? _7 = &mut _8;
? ? _6 = &mut (*_7);
? ? _10 = const "b";
? ? _9 = _10;
? ? _5 = <String as AddAssign<&str>>::add_assign(move _6, move _9) -> [return: bb3, unwind: bb5];
}
這很容易解釋 +=
的語(yǔ)法脫糖和真正的執(zhí)行順序:
-
_4 = CheckedAdd((*_2), _1)
這里的執(zhí)行順序是從右到左(注意觀察編號(hào)),并且不是調(diào)用<i32 as AddAssign<i32>>::add_assign
,
而是直接調(diào)用 CheckedAdd
函數(shù)。
- 而
add_assign!(1, &2)
則對(duì)應(yīng)_1 = <i32 as AddAssign<&i32>>::add_assign(move _2, move _13) -> bb5
,順序從左到右,調(diào)用了重載的
+=
trait 方法。
-
_5 = <String as AddAssign<&str>>::add_assign(move _6, move _9)
這里的順序是從左到右,調(diào)用的是重載的+=
trait 方法。
單一實(shí)現(xiàn)下的強(qiáng)轉(zhuǎn)
遵循前面我提到的流程,對(duì)于以下正常工作代碼,第一步,寫下左右兩側(cè)的類型,你會(huì)得到 S += &&&&&&()
,實(shí)際不存在這個(gè)實(shí)現(xiàn),因?yàn)?br>S
僅有 S: AddAssign<&()>
。這發(fā)生了什么?
struct S; impl std::ops::AddAssign<&()> for S { fn add_assign(&mut self, _: &()) {} } fn main() { let mut s = S; let rrrrrr = &&&&&&(); s += rrrrrr; }
通過 MIR,你會(huì)發(fā)現(xiàn)
-
<S as AddAssign<&()>>::add_assign(move _4, move _5)
表明從左到右執(zhí)行,因?yàn)閮蓚?cè)運(yùn)算數(shù)不是 primitive type - 傳給
add_assign
的第二個(gè)參數(shù),其類型并不是變量rrrrrr
的類型&&&&&&()
,而是經(jīng)過 5 次解引用之后的&()
類型
bb0: { _6 = const _; _4 = &mut _1; _7 = deref_copy (*_2); _8 = deref_copy (*_7); _9 = deref_copy (*_8); _10 = deref_copy (*_9); _11 = deref_copy (*_10); _5 = _11; _3 = <S as AddAssign<&()>>::add_assign(move _4, move _5) -> bb1; }
這里隱式的解引用是因?yàn)閺?qiáng)轉(zhuǎn),而函數(shù)參數(shù)是能夠發(fā)生 強(qiáng)轉(zhuǎn)的地方 之一。
并且,依據(jù)這段 MIR(注意看從上到下的執(zhí)行過程),我們知道,對(duì)于已知的 add_assign
實(shí)現(xiàn),執(zhí)行順序先于強(qiáng)轉(zhuǎn)發(fā)生。
而當(dāng) S
的 AddAssign
實(shí)現(xiàn)是多個(gè),強(qiáng)轉(zhuǎn)被阻止,你需要傳入準(zhǔn)確的類型的值:
struct S; impl std::ops::AddAssign<()> for S { fn add_assign(&mut self, _: ()) {} } impl std::ops::AddAssign<&()> for S { fn add_assign(&mut self, _: &()) {} } fn main() { let mut s = S; let rrrrrr = &&&&&&(); s += rrrrrr; } // error[E0277]: cannot add-assign `&&&&&&()` to `S` // --> src/main.rs:12:7 // | // 12 | s += rrrrrr; // | ^^ no implementation for `S += &&&&&&()` // | // = help: the trait `AddAssign<&&&&&&()>` is not implemented for `S` // = help: the following other types implement trait `AddAssign<Rhs>`: // <S as AddAssign<&()>> // <S as AddAssign<()>>
兩階段借用的參與
以下代碼能夠運(yùn)行:
- 由于兩側(cè)類型不是 primitive type,
add_assign
從左到右執(zhí)行 - 但已經(jīng)使用
&mut self
的情況下,為什么能夠同時(shí)執(zhí)行帶&self
的方法?
struct S; impl std::ops::AddAssign<()> for S { fn add_assign(&mut self, _: ()) {} } impl S { fn no_op(&self) {} } fn main() { let mut s = S; s += s.no_op(); }
通常對(duì)于初學(xué)者, &mut
會(huì)有兩個(gè)更高級(jí)的主題:
- 重新借用 (reborrow)
- open 狀態(tài)的 Reference issue、RFC issue,在遷移到 Chalk 之前,不會(huì)正式描述 reborrow
- 它大概是說:我們看見的
&'a mut T
,實(shí)際被自動(dòng)轉(zhuǎn)化成更短的&'b mut T
,從而看起來&mut T
一直可用。這也發(fā)生在 -
&T
上面,但通常我們對(duì)&mut T
的 reborrow 更敏感。 - 這一是個(gè)在 1.0 之前就有的概念
- UCG 可能會(huì)對(duì) reborrow 做出說明
- 一個(gè)直覺上的理解
- 兩階段借用 (two-phase borrows)
- 它在 rustc dev guide 上的 正式介紹
- 它大概是說,某些情況下
&mut T
會(huì)劃分成兩個(gè)階段進(jìn)行使用: - 在 reservation 階段:
&mut T
像是&T
那樣,以允許多個(gè)&T
同時(shí)存在 - 在 activated 階段:
&mut T
以完全獨(dú)占的方式使用 - 某些情況指以下三種情況之一(上述鏈接對(duì)具體例子都有分析):
- 調(diào)用 receiver 為
&mut self
的方法(包括方法調(diào)用時(shí)的自動(dòng)引用):如vec.push(vec.len())
- 函數(shù)參數(shù)中的
&mut T
reborrow:如std::mem::replace(r, vec![r.len()])
- 重載的復(fù)合賦值運(yùn)算符中隱式的
&mut T
:如本小節(jié)示例 - 代碼中,任何顯式的
&mut
和ref mut
都不是兩階段借用
MIR 可以幫助你看到兩階段借用。
bb0: { // reservation 階段 _3 = &mut _1; // 兩階段借用的第三種前提:重載的復(fù)合賦值運(yùn)算符中隱式的 `&mut T` _5 = &_1; // `&mut T` 暫時(shí)被視為 `&T`,從而允許在此處使用 `&T` _4 = S::no_op(move _5) -> bb1; } bb1: { // activated 階段 _2 = <S as AddAssign<()>>::add_assign(move _3, move _4) -> bb2; }
實(shí)戰(zhàn)
例子源自 #72199 issue,@steffahn 做了很好的 解釋,這里從 MIR 角度進(jìn)行補(bǔ)充。
Vec<i32>
的 v[i] += v[j]
fn main() { let mut v = Vec::from([0, 1]); // 為了讓 MIR 精簡(jiǎn),故意不使用 vec![0, 1] v[0] += v[1]; // 第一步:i32 += i32 } // 兩側(cè)為 primitive types, RTL: <i32 as Add<i32>>::add_assign(&mut v[0], v[1]) // 1. 計(jì)算 v[1]:對(duì)它脫糖 `<Vec<i32> as Index<usize>>::index(&v, 1)` 得到 `&i32`,然后解引用得到 `i32` // 2. 計(jì)算 &mut v[0]:對(duì)它脫糖 `<Vec<i32> as IndexMut<usize>>::index_mut(&mut v, 0)` 得到 `&mut i32` // 可以看到先使用了 `&v`,再使用了 `&mut v`,通過借用檢查 // 僅列出 MIR 中的重點(diǎn) // let mut _1: std::vec::Vec<i32>; // bb1: { // _5 = &_1; // _4 = <Vec<i32> as Index<usize>>::index(move _5, const 1_usize) -> [return: bb2, unwind: bb6]; // } // bb2: { // _3 = (*_4); // _7 = &mut _1; // _6 = <Vec<i32> as IndexMut<usize>>::index_mut(move _7, const 0_usize) -> [return: bb3, unwind: bb6]; // } // bb3: { // _8 = CheckedAdd((*_6), _3); // assert(!move (_8.1: bool), "attempt to compute `{} + {}`, which would overflow", (*_6), move _3) -> [success: bb4, unwind: bb6]; // } // bb4: { // (*_6) = move (_8.0: i32); // drop(_1) -> bb5; // }
&mut [Custom]
的 v[i] += v[j]
#[derive(Clone, Copy)] struct MyNum(i32); impl std::ops::AddAssign for MyNum { fn add_assign(&mut self, rhs: MyNum) { *self = MyNum(self.0 + rhs.0) } } fn main() { let mut b = vec![MyNum(0), MyNum(1)]; let v = b.as_mut_slice(); v[0] += v[1]; // MyNum += MyNum } // LTR: <MyNum as Add<MyNum>>::add_assign(&mut v[0], v[1]) // 1. 計(jì)算 &mut v[0]:獲取和維持對(duì)第 0 元素的獨(dú)占引用,但只進(jìn)入 reservation 階段,將 &mut 視為 &,從而繼續(xù)使用切片 // 2. 計(jì)算 v[1]:在 `&mut v[0]` 的第一階段,通過 `*_10` 和索引拷貝 MyNum // 3. 調(diào)用方法,`&mut v[0]` 進(jìn)入 activated 階段 // 僅列出 MIR 中的重點(diǎn) // let mut _1: std::vec::Vec<MyNum>; // bb2: { // _11 = &mut _1; // _10 = Vec::<MyNum>::as_mut_slice(move _11) -> [return: bb3, unwind: bb8]; // } // bb3: { // 索引前進(jìn)行了邊界檢查 // _14 = const 0_usize; // _15 = Len((*_10)); // _16 = Lt(_14, _15); // assert(move _16, "index out of bounds: the length is {} but the index is {}", move _15, _14) -> [success: bb4, unwind: bb8]; // } // bb4: { // _13 = &mut (*_10)[_14]; // 獲取 &mut v[0],進(jìn)入 reservation 階段 // _18 = const 1_usize; // 索引前進(jìn)行了邊界檢查 // _19 = Len((*_10)); // _20 = Lt(_18, _19); // assert(move _20, "index out of bounds: the length is {} but the index is {}", move _19, _18) -> [success: bb5, unwind: bb8]; // } // bb5: { // _17 = (*_10)[_18]; // 計(jì)算 v[1] // _12 = <MyNum as AddAssign>::add_assign(move _13, move _17) -> [return: bb6, unwind: bb8]; // activated 階段 // }
Vec<Custom>
的 v[i] += v[j]
#[derive(Clone, Copy)] struct MyNum(i32); impl std::ops::AddAssign for MyNum { fn add_assign(&mut self, rhs: MyNum) { *self = MyNum(self.0 + rhs.0) } } fn main() { let mut b = vec![MyNum(0), MyNum(1)]; b[0] += b[1]; }
它無法編譯成功,但編譯器提示你怎么 解決(把右側(cè)的值賦給局部變量,然后使用該變量):
error[E0502]: cannot borrow `b` as immutable because it is also borrowed as mutable --> src/main.rs:12:13 | 12 | b[0] += b[1]; | --------^--- | | | | | immutable borrow occurs here | mutable borrow occurs here | mutable borrow later used here | help: try adding a local storing this... --> src/main.rs:12:13 | 12 | b[0] += b[1]; | ^^^^ help: ...and then using that local here --> src/main.rs:12:5 | 12 | b[0] += b[1]; | ^^^^^^^^^^^^
當(dāng)你試著從 MIR 分析為什么這樣,你會(huì)發(fā)現(xiàn) playground 因?yàn)榫幾g失敗而沒有 MIR 的結(jié)果,提示為Unable to locate file for Rust MIR output
。
此時(shí),你仍可以在本地獲取一部分 MIR 結(jié)果,因?yàn)?MIR 其實(shí)經(jīng)過許多次迭代,mir_dump
文件夾下保留了半成品:運(yùn)行cargo rustc -- -Z dump-mir=main
,查看 mir_dump/simd.main.-------.renumber.0.mir
文件。
// 僅列出關(guān)鍵部分 bb4: { _13 = &mut _1; _12 = <Vec<MyNum> as IndexMut<usize>>::index_mut(move _13, const 0_usize) -> [return: bb5, unwind: bb9]; } bb5: { _11 = &mut (*_12); StorageDead(_13); StorageLive(_14); StorageLive(_15); StorageLive(_16); _16 = &_1; _15 = <Vec<MyNum> as Index<usize>>::index(move _16, const 1_usize) -> [return: bb6, unwind: bb9]; } bb6: { _14 = (*_15); StorageDead(_16); _10 = <MyNum as AddAssign>::add_assign(move _11, move _14) -> [return: bb7, unwind: bb9]; }
把它與上一小節(jié)在 &mut [MyNum]
的 MIR 進(jìn)行對(duì)比,你會(huì)發(fā)現(xiàn)在 &mut Vec<MyNum>
上沒有發(fā)生兩階段借用:
- 觀察兩個(gè) MIR 片段的
move _13
,第二個(gè)片段的&mut _1
借用已經(jīng)在獲取索引時(shí)結(jié)束(未能到達(dá)add_assign
),而第一個(gè)在調(diào)用add_assign
時(shí)結(jié)束 - 所以
Vec<MyNum>
上的b[0] += b[1]
是通過兩個(gè)不同的&mut Vec<MyNum>
和&Vec<MyNum>
,分別得到&mut MyNum
和MyNum
兩個(gè)操作數(shù)
而 Rust 的借用檢查不允許在一個(gè)函數(shù)調(diào)用中對(duì)同一個(gè)值同時(shí)使用 &mut
和 &
,從而編譯報(bào)錯(cuò)。
// b[0] += b[1] on &mut [MyNum] _10 = Vec::<MyNum>::as_mut_slice(move _11) // _10: &mut [MyNum] _13 = &mut (*_10)[_14]; // two-phase _17 = (*_10)[_18]; // reservation 階段 _12 = <MyNum as AddAssign>::add_assign(move _13, move _17) // activated 階段 // b[0] += b[1] on Vec<MyNum> _13 = &mut _1; // _1: Vec<MyNum> _12 = <Vec<MyNum> as IndexMut<usize>>::index_mut(move _13, const 0_usize) // _13: &mut Vec<MyNum>, _12: &mut MyNum _11 = &mut (*_12); // reborrow _16 = &_1; _15 = <Vec<MyNum> as Index<usize>>::index(move _16, const 1_usize) // _16: &Vec<MyNum>, _15: &mut MyNum _14 = (*_15); _10 = <MyNum as AddAssign>::add_assign(move _11, move _14)
- 總結(jié)
+=
是可重載的復(fù)合賦值運(yùn)算符,Self += Rhs
脫糖為<Self as AddAssign<Rhs>>::add_assign(&mut Self, Rhs)
,但 - 對(duì)兩側(cè)為 primitive types 的運(yùn)算數(shù),先計(jì)算
Rhs
,再計(jì)算Self
,然后調(diào)用編譯器實(shí)現(xiàn)的相加函數(shù) - 若至少有一側(cè)運(yùn)算數(shù)不為 primitive types,則先計(jì)算
Self
,再計(jì)算Rhs
,然后調(diào)用重載后的實(shí)現(xiàn)(即<Self as AddAssign<Rhs>>::add_assign
) - 大多數(shù)表達(dá)式是從左到右執(zhí)行的。從右到左是特殊情況,比如
- 賦值表達(dá)式中,先計(jì)算
=
右側(cè)的值,再計(jì)算左側(cè) - 復(fù)合賦值表達(dá)式中,兩側(cè)為 primitive types 的運(yùn)算數(shù)時(shí),先計(jì)算復(fù)合賦值運(yùn)算符右側(cè),再計(jì)算左側(cè)
- MIR 是 Rust 編譯過程的重要一環(huán),(無論在代碼編譯成功還是失敗的情況下)也可以成為輔助你分析的 Rust 代碼的工具
一個(gè)例子
另一個(gè)例子?
拓展閱讀:運(yùn)用這套流程分析
==
操作符的具體的例子?
原文鏈接:https://blog.csdn.net/m0_37952030/article/details/128805020
相關(guān)推薦
- 2022-07-07 Python使用captcha庫(kù)制作帶參數(shù)輸入驗(yàn)證碼案例_python
- 2022-09-08 Go語(yǔ)言中的包Package詳解_Golang
- 2022-11-25 Python隨機(jī)值生成的常用方法總結(jié)_python
- 2022-08-17 C++詳解如何通過模板實(shí)現(xiàn)元素的反序_C 語(yǔ)言
- 2022-11-13 Redis中HyperLogLog的使用詳情_Redis
- 2021-12-07 bitbucket搭建詳細(xì)過程記錄_其它綜合
- 2022-08-11 C#中using關(guān)鍵字的使用方法示例_C#教程
- 2022-10-21 React實(shí)現(xiàn)動(dòng)態(tài)調(diào)用的彈框組件_React
- 最近更新
-
- window11 系統(tǒng)安裝 yarn
- 超詳細(xì)win安裝深度學(xué)習(xí)環(huán)境2025年最新版(
- Linux 中運(yùn)行的top命令 怎么退出?
- MySQL 中decimal 的用法? 存儲(chǔ)小
- get 、set 、toString 方法的使
- @Resource和 @Autowired注解
- Java基礎(chǔ)操作-- 運(yùn)算符,流程控制 Flo
- 1. Int 和Integer 的區(qū)別,Jav
- spring @retryable不生效的一種
- Spring Security之認(rèn)證信息的處理
- Spring Security之認(rèn)證過濾器
- Spring Security概述快速入門
- Spring Security之配置體系
- 【SpringBoot】SpringCache
- Spring Security之基于方法配置權(quán)
- redisson分布式鎖中waittime的設(shè)
- maven:解決release錯(cuò)誤:Artif
- restTemplate使用總結(jié)
- Spring Security之安全異常處理
- MybatisPlus優(yōu)雅實(shí)現(xiàn)加密?
- Spring ioc容器與Bean的生命周期。
- 【探索SpringCloud】服務(wù)發(fā)現(xiàn)-Nac
- Spring Security之基于HttpR
- Redis 底層數(shù)據(jù)結(jié)構(gòu)-簡(jiǎn)單動(dòng)態(tài)字符串(SD
- arthas操作spring被代理目標(biāo)對(duì)象命令
- Spring中的單例模式應(yīng)用詳解
- 聊聊消息隊(duì)列,發(fā)送消息的4種方式
- bootspring第三方資源配置管理
- GIT同步修改后的遠(yuǎn)程分支