C error

V version: V 0.4.9 9fc8352, press to see full `v doctor` output

V full version	V 0.4.9 `6ac1d08`.9fc8352
OS	linux, "Void Linux"
Processor	4 cpus, 64bit, little endian, Intel(R) Pentium(R) Gold 7505 @ 2.00GHz
Memory	17.37GB/23.16GB

V executable	/home/nopana/v/v
V last modified time	2025-01-07 23:24:19

V home dir	OK, value: /home/nopana/v
VMODULES	OK, value: /home/nopana/.vmodules
VTMP	OK, value: /tmp/v_1000
Current working dir	OK, value: /home/nopana/projects/notOnlyNots

Git version	git version 2.47.1
V git status	weekly.2024.52-90-g9fc83526
.git/config present	true

cc version	cc (GCC) 13.2.0
gcc version	gcc (GCC) 13.2.0
clang version	N/A
tcc version	tcc version 0.9.28rc 2024-07-31 HEAD@1cee0908 (x86_64 Linux)
tcc git status	thirdparty-linux-amd64 0134e9b9
emcc version	N/A
glibc version	ldd (GNU libc) 2.39

What did you do?
./v -g -o vdbg cmd/v && ./vdbg main.v && main
above is the command v bug uses, but I used : v run main.v

import gg

struct App {
mut:
	ctx &gg.Context = unsafe { nil }
}

fn main() {
	mut app := &App{}
	app.ctx = gg.new_context(
		user_data: app
		event_fn:  on_event
	)
}

fn on_event(e &gg.Event, mut app App) {
	_ := match [0, 0]! {
		[0, 1]! {
			0
		}
		else {
			panic('')
		}
	}
}

What did you see?

================== C compilation error (from tcc): ==============
cc: /tmp/v_1000/main.01JH1KEX3FBGZXDNT5792TSTVY.tmp.c:11467: error: expression expected before '{'
=================================================================
(You can pass `-cg`, or `-show-c-output` as well, to print all the C error messages).
builder error: 
==================
C error found. It should never happen, when compiling pure V code.
This is a V compiler bug, please report it using `v bug file.v`,
or goto https://github.com/vlang/v/issues/new/choose .
You can also use #help on Discord: https://discord.gg/vlang .

What did you expect to see?

No C error

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

Wow! C appart, and fixed arrays appart, I didn't know V permitted to set non-constant match options!
This code is accepted:

fn check(a int, b int, c int) string {
	return match a {
		b { 'b' }
		c { 'c' }
		else { 'other' }
	}
}

fn main() {
	println('${check(1,1,1)}') // b
	println('${check(1,0,1)}') // c
	println('${check(1,0,0)}') // other
}

even though in check(1,1,1) call variables b and c are equal which is not permitted normally.

Next code is rejected but is weird:

fn check_2(a int) string {
	return match a {
		a { 'first a' } // accepted line (but why?)
		a { 'second a' }  // ofending line
		else { 'else' }
	}
}

produces:

match case `a` is handled more than once

Well, a will always match a...

You a, b, c example works because they are separate variables, even if they have the same contents. Otherwise, check(1, 1, 2) wouldn't work, neither would check(2, 1, 2), etc. check(1, 2, 3) will fall into the else, since the contents of a don't match either of the other 2.

In fact, you can match on ranges, on the results of fn calls, etc. - anything that matches the type of the variable you're matching against.

This code is accepted and always prints a. Never 1, never else... even though the programmer thinks they would be possible.

fn check_3(a int) string {
	return match a {
		a { 'a' } // accepted line (but why?)
		1 { '1' }
		else { 'else' }
	}
}

This program can print 1, otherwise just a, but never else because I moved 1 as first match!

fn check_4(a int) string {
	return match a {
		1 { '1' }
		a { 'a' } // accepted line (but why?)
		else { 'else' }
	}
}

Incorrect. It will only print 1 if you call it with check_4(1). Otherwise, it will print a, since a always matches a.

fn check_4(a int) string {
        return match a {
                1 { '1' }
                a { 'a' }
                else { 'else' }
        }
}

println(check_4(1))
println(check_4(2))
println(check_4(3))

output is

1
a
a

Your check_3 will always print a, because a always matches a, and that is checked first.

JalonSolov: For fn check_4(a int) string { I said the same you said. Anyway, imho the possibility of dead code is important so I open issue #23404 to consider to send a warning.

Returning to the origin of this post, seems to me the branch of 0 is dead code, because never [0,0]! will be equal to [0,1]!:

fn on_event(e &gg.Event, mut app App) {
	_ := match [0, 0]! {
		[0, 1]! {
			0
		}
		else {
			panic('')
		}
	}

Yes, if and only if the compiler accepts such fixed array as comparable variables.

cgen: fix codegen for array fixed comparison on MatchExpr (fix #23403) (

Navigation Menu

Repository navigation

C error #23403

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

C error #23403

Description

Activity

jorgeluismireles commented on Jan 8, 2025

JalonSolov commented on Jan 8, 2025

jorgeluismireles commented on Jan 8, 2025

jorgeluismireles commented on Jan 8, 2025

JalonSolov commented on Jan 8, 2025

JalonSolov commented on Jan 8, 2025

jorgeluismireles commented on Jan 8, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions