Result depending on execution order

[llogiq]

In Rust issue #28160, Niko shows an example containing the line x += { x = 20; 2 }, and asks the question what execution order should be used.

I think we should have a lint against those degenerate cases. However, I'm not sure what patterns we should match.

issues left:

• simple cases with one variable
• struct/tuple fields (easy)
• taking a reference to a field stops the lint from checking any further, even if it is dereferenced again (medium)

[Manishearth]

Marking as easy, but a more involved (medium difficulty) check is also possible using visitors.

[oli-obk]

The simple cases are caught now, added list of remaining things.

[scurest]

Actually, I forgot that Rust will let you take the address of a temporary by prolonging its lifetime. So although I was thinking &{...; x} would somehow take the address of x, of course it only copies x and takes the address of that copy. So the final tickbox is easy; when you find the variable, just check if the parent expression is ExprAddrOf and don't lint if it is. The second box is the harder one :D

So to check, is there any case where a variable appears in an expression but isn't read other than

• on the left side of an assignment; x = ...
• directly under a &; &x or &mut x, or
• inside of a closure?

[oli-obk]

What about x = (x+=1, *&x).1? Won't the reference stop the linting, too?

[scurest]

Yes, but generally it's hard to decide whether the address is dereferenced! For example, (x = 1, p = &x) is fine, but (x = 1, {p = &x; q = p; *q}) is not and whether

(x = 1, {
    a[0] = &x;
    *a[/*arbitrary expression */]
})

is fine is undecidable. Similarly for closures ((x = 1, c = || { x = 2 }) is fine...). So I was just planning on letting those pass. A more complicated check is definitely more difficult though.