Don't understand error "Reference aliases sibling expression"

[tmssngr]

I have following code

struct Options {
  port: string
}

fn configure(options: Ref<Options>) -> bool {
  ...
}

...
  let mut options = Options{
    port: "",
  }
  ...
  match choice {
    0 => {
      let _ = configure(&options)
      continue
    },
    1 => {
      if options.port.is_empty() && !configure(&options) {
        continue
      }
  ...

and get following error

  ✕ Reference aliases sibling expression
     ╭─[src/main.lis:198:46]
 197 │             1 => {
 198 │                 if options.port.is_empty() && !configure(&options) {
     ·                                                          ────┬───
     ·                                                              ╰── &options could mutate options used by a sibling
 199 │                     continue
     ╰────
  help: Bind options to a let before this expression to make evaluation order explicit · code: [infer.reference_aliases_sibling]

which I do not understand. Does it now use some kind of ownership/borrow semantics?

[ivov]

Hi Thomas!

Lisette has no ownership semantics. Ref<T> is a plain Go pointer.

The lint you hit fires inside a compound expression, when one part takes &n (a pointer that could mutate n) while another part reads n directly. The intent is to catch cases where the value a sibling reads depends on whether &n evaluated first:

let mut n = 1
let pair = (inc(&n), n)

In your case, the lint is a false positive because && short circuits, so there's no subtle evaluation order to be made explicit. I'll tighten the lint and make the help text clearer. Tracking at #1047.

[ivov]

For the record, a curt "not really" on feedback I acted on isn't something I can work with, and it isn't the tone I want in this project. I'm always happy to keep improving things when the feedback is specific.

[tmssngr]

Sorry for being so short, but what exactly the check complains about? Is it about an undefined order in which the arguments of the tuple are evaluated (like it would be with function arguments in C)? Would it also occur for function arguments? Why is it an error and not just a warning? Is the expected solution to evaluate the first tuple argument in a separate statement? Would there be a warning, too, if a called function would change a global variable?

[ivov]

The check flags where an earlier part of an expression passes &v into a call that can mutate v, while a later part reads bare v:

let pair = (store(&total, 5), total)

Operands evaluate left-to-right in the generated code (deterministically, via temps), so the read isn't undefined, it just silently picks up the sibling's mutation, but this is very easy to misread. Writing the two separately makes the intent explicit:

let stored = store(&total, 5)
let pair = (stored, total)

In the flagged spot, a bare total reads as "the value of total", not "the value store overwrote just now", so the code very likely does something other than what it looks like, which is a bug waiting to happen. It's a judgment call on warning vs error, but since there are two plausible readings that produce different behavior, I'd rather block the ambiguity from getting to runtime.

[tmssngr]

For me

let pair = (store(&total, 5), total)

and

let stored = store(&total, 5)
let pair = (stored, total)

look identical. Will the warning trigger on the latter, too, or just if &v and v are used in the same statement?

[ivov]

The two-line rewrite won't trigger it - it's the fix, not another violation. The check compares operands only within a single expression.

As for the reasoning, operand order is deterministic, so nothing is C-style UB. The check exists because the flagged form is easy to misread, i.e. the code does something other than what it looks like it says.

let a = (total, store(&total, 5)) // a is (1, 5)
let b = (store(&total, 5), total) // b is (5, 5)

The rewrite changes nothing about behavior but removes the second reading. Once the call is its own statement, top-to-bttom order gives the only possible answer.