Fix if expressions in lock expression

[crthpl]

No description provided.

[medvednikov]

the removals of & seem to be unrelated to the PR?

[crthpl]

shared implies a reference and the underlying type looks like this;

struct __shared__Array_int {
	sync__RwMutex mtx;
	Array_int val;
};

and then whenever you creacte a shared foo, you create a reference to __shared__Array_int, not the Array_int:

__shared__Array_int* foo = (__shared__Array_int*)__dup_shared_array(&(__shared__Array_int){.mtx = {0}, .val =
new_array_from_c_array(3, 3, sizeof(int), _MOV((int[3]){2, 0, 5}))}, sizeof(__shared__Array_int));

This was generated with current V, and it didn't generate a reference to the array anyways.
This PR makes assignments always use expr_with_cast, which doesn't allow casting a reference to shared:

v/vlib/v/gen/c/cgen.v

Line 2212 in cee7856

g.error('cannot convert reference to `shared`', expr.pos())

You need a reference to __shared__Array_int because the mutexes all need to be the same one in memory, and having a shared reference is usually (always?) never what you want.

[spytheman]

This cgen error is not triggered by any of the existing tests, and the tests that are changed, compile fine on both master and the branch of this PR.

[spytheman]

The file vlib/v/tests/shared_if_expr_test.v is the only test file that should stay in the PR imho.

[spytheman]

For example the change in vlib/sync/array_rlock_test.v is not related to the PR:

[medvednikov]

@spytheman he's removing unnecessary &[] from the code. It's already handled by V when it sees it's shared.

[spytheman]

I understand that.
But it is handled by V now.
It is not guaranteed to be handled by V in the future.
By not changing these tests, it would be, because they will break and the CI will tell us when that happens.

[spytheman]

btw, I have no objections to making it an explicit checker error, and a corresponding test for it.

[medvednikov]

I see, ok I agree.