Detect assignments in calls to avoid false positive lints

[lionel-]

Addresses posit-dev/positron#3048.

Positron Notes

Release Notes

New Features

• N/A

Bug Fixes

• Assignments in function calls (e.g. list(x <- 1)) are now detected by the missing symbol linter to avoid annoying false positive diagnostics (Diagnostics: No symbol in scope when assigning variables in function calls positron#3048). The downside is that this causes false negatives when the assignment happens in a call with local scope, e.g. in local() or test_that(). In these cases the nested assignments will incorrectly overlast the end of the call. We prefer to be overly permissive than overly cautious in these matters.

QA Notes

Assignments in calls, e.g. list(x <- 1) should now be treated the same as at top-level. Any further references to x at top level should not be linted, e.g. y should cause a lint but not x in:

list(x <- 1)
x; y

Note that calls can be nested list(x <- 1, list(y, x, y <- 2), 1, y).

In that example, the first y should in principle be linted as it hasn't been defined yet but we don't support this sort of lints inside arguments yet.

[lionel-]

This is the crux of the fix. We don't create a new context so that assignments may apply to the caller's context.

[DavisVaughan]

// We used to clone `context` here to prevent assignments from applying to // the caller.

Honestly i dont even think that was the original reason

we cloned just so we could set in_call for that scope and its children scopes, but we tried to avoid leaking in_call = true outside of this scope
1710415

i think i was just copying some existing pattern being used in diagnostics, see other context.clone() calls in there

in retrospect your approach of setting it and making sure to reset the old value on the way out makes more sense in general, i think