cgen error for using multiplication on a matched value, inside a type match branch, on an interface

[spytheman]

V doctor:

V full version: V 0.4.0 63867d4
OS: linux, Ubuntu 20.04.6 LTS
Processor: 4 cpus, 64bit, little endian, Intel(R) Core(TM) i3-3225 CPU @ 3.30GHz

getwd: /v/vnew
vexe: /v/vnew/v
vexe mtime: 2023-07-17 12:43:40

vroot: OK, value: /v/vnew
VMODULES: OK, value: /home/delian/.vmodules
VTMP: OK, value: /tmp/v_1000

Git version: git version 2.41.0
Git vroot status: weekly.2023.28-29-g63867d4c
.git/config present: true

CC version: cc (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
thirdparty/tcc status: thirdparty-linux-amd64 12f392c3

What did you do?
v -g -o vdbg cmd/v && vdbg bug.v

interface Any {}

fn do(v Any) {
	match v {
		int {
			println('> integer answer: ${2 * v}')
		}
		string {
			println('> string answer: ${v}, len: ${v.len}')
		}
		else {}
	}
}

fn main() {
	do(123)
	do('abc')
}

What did you expect to see?

a compiled program

What did you see instead?

==================
/tmp/v_1000/bug.7680024232381024934.tmp.c:12581: error: invalid operand types for binary operation
...
==================
(Use `v -cg` to print the entire error message)

builder error: 
==================
C error. This should never happen.

This is a compiler bug, please report it using `v bug file.v`.

https://github.com/vlang/v/issues/new/choose

You can also use #help on Discord: https://discord.gg/vlang

Note, that using println('> integer answer: ${2 * *v}') compiles cleanly.

Imho the problem, is somewhat related to the fact that v is not properly auto dereferenced inside the match branch - it gives the illusion, that it can be used as a value, but instead v is a pointer, but then the checker allowed 2 * v, and then cgen, generated code for number * pointer which of course does not compile.

Imho either it should have been auto dereferenced, so that it in essence it should have generated code for 2 * (*v), or there should have been a checker error, that required a manual dereferencing, not allowing me to do 2 * v on the V side.

[JalonSolov]

I would vote for the auto-dereference option, as that makes the most logical sense looking at the code. It exposes too much of the internal implementation to have to use *v instead of just v.