c++ - Rust 中的 "sequence point"/"sequenced-before"规则是什么？

Question

Rust 中的规则是什么，类似于这里描述的规则http://en.cppreference.com/w/cpp/language/eval_order对于 C++？

目前我凭经验发现，
1) 函数的参数按直接顺序求值
2) 所有有副作用的内置操作(=、+=、-= 等)返回单位，因此很难(但可能)组成表达式，这将在 C++ 中显示 UB。
一个例子:

let mut a = 1i;
let b = 2i;
let c = 3i;
let d = (a = b) == (a = c); // What is a? (a is actually 3)

3) 似乎函数调用的顺序与 C++ 中的一样
4) 似乎内置操作的顺序就像它们是函数(方法)调用一样，即求值顺序与运算符优先级相关

我的结论正确吗？具体的评估模型是什么？

Answer 1

我不相信它已被明确定义，我对 the manual 的 grepping没有出现任何东西。但是，我可以保证这些东西不会是未定义的行为(Rust 明确地避免了 unsafe 代码之外的 UB)，如果它不是“从左到右”，即你的顺序，我会感到惊讶推导。虽然，分辨率为#6268可能导致方法最后评估接收器(或者可能不是，这只是一种可能性)。

我打开了#15300 .

---

顺便说一句，如果你正在研究这个，你可以让编译器用精确的评估顺序拆分出漂亮的控制流图(注意。这都是内部 API，因此不能依赖, 比正常情况下更有可能使编译器崩溃，并且不隐藏编译器实现细节:它主要是为从事 rustc 工作的人员设计的。

正如@pnkfelix 指出的那样，编译器并未使用 CFG 进行代码生成(截至 2014 年 7 月 2 日)，这意味着不能保证 CFG 完全准确。

例如采用@ChrisMorgan 示例之一的精简版:

fn foo(_: (), x: int) -> int {
    x
}

fn main() {
    let mut a = 1;
    { // A
        a * foo(a = 3, a)
    };
}

我们希望编译器在某个 block (即 { ... } )中拆分出语句/表达式的控制流图，这可以通过 --pretty flowgraph=<nodeid> 来完成编译器的选项，但为此我们需要有我们感兴趣的 block 的 ID。在这种情况下，我们想要的 block 是 A .使用 rustc --pretty expanded,identified 获取 id 编译(请注意，仅使用 identified 是毫无意义的:id 现在仅在宏扩展后分配):

#![feature(phase)]
#![no_std]
#![feature(globs)]
#[phase(plugin, link)]
extern crate std = "std#0.11.0-pre";
extern crate native = "native#0.11.0-pre";
use std::prelude::*;
fn foo(_ /* pat 7 */: (), x /* pat 11 */: int) -> int { (x /* 15 */) } /*
block 14 */ /* 4 */

fn main() {
    let mut a /* pat 22 */ = (1 /* 23 */);
    ({
         ((a /* 28 */) *
             ((foo /* 30
                  */)(((a /* 32 */) = (3 /* 33 */) /* 31 */), (a /* 34 */)) /*
                 29 */) /* 27 */)
     } /* block 26 */ /* 25 */);
} /* block 18 */ /* 16 */

很多令人讨厌的内部垃圾，但我们需要的东西在评论中有 /* block 26 */ . rustc --pretty flowgraph=26给出一个点文件，呈现如下。您可以引用上面的标识符注释源来准确计算每个表达式的含义(id = .. 位):

(抱歉，很长，显然这段代码没有分支，所以只是一长串操作。)

FWIW，该表达式的计算结果为 9 ，而我期待 3 (并且控制流图确认 LHS 上的隔离 a 在 RHS 之后被评估，包括那里的 a = 3)。我已经在 #15300(e: 和现在的 isolated it to a strange difference in evaluation order )上提出了这个问题。