cgen: fix interface _name_table generation; closes issue #73
							parent
							
								
									0e7192c9b7
								
							
						
					
					
						commit
						3b94a2b77a
					
				|  | @ -5598,9 +5598,6 @@ fn (mut g Gen) interface_table() string { | |||
| 			continue | ||||
| 		} | ||||
| 		inter_info := ityp.info as table.Interface | ||||
| 		if inter_info.types.len == 0 { | ||||
| 			continue | ||||
| 		} | ||||
| 		// interface_name is for example Speaker
 | ||||
| 		interface_name := c_name(ityp.name) | ||||
| 		// generate a struct that references interface methods
 | ||||
|  |  | |||
|  | @ -0,0 +1,31 @@ | |||
| // The series of i?_test.v files, do test different edge cases for
 | ||||
| // interface table generation. The differences may seem very minor
 | ||||
| // (placement of the interface declaration, whether or not there are
 | ||||
| // helper methods, etc), but PLEASE do NOT be tempted to merge them in
 | ||||
| // a single _test.v file. Debugging interface code generation issues
 | ||||
| // is *much easier* when the _test.v files are very short and focused.
 | ||||
| struct Point { | ||||
| 	x i8 | ||||
| 	y i8 | ||||
| } | ||||
| 
 | ||||
| fn (p Point) draw() string { | ||||
| 	return 'Point($p.x,$p.y)' | ||||
| } | ||||
| 
 | ||||
| fn to_string(d Drawer) { | ||||
| 	println(d.draw()) | ||||
| } | ||||
| 
 | ||||
| interface Drawer { | ||||
| 	draw() string | ||||
| } | ||||
| 
 | ||||
| fn test_to_string_can_be_called() { | ||||
| 	p := Point{ | ||||
| 		x: 2 | ||||
| 		y: 3 | ||||
| 	} | ||||
| 	to_string(p) | ||||
| 	assert true | ||||
| } | ||||
|  | @ -0,0 +1,34 @@ | |||
| // The series of i?_test.v files, do test different edge cases for
 | ||||
| // interface table generation. The differences may seem very minor
 | ||||
| // (placement of the interface declaration, whether or not there are
 | ||||
| // helper methods, etc), but PLEASE do NOT be tempted to merge them in
 | ||||
| // a single _test.v file. Debugging interface code generation issues
 | ||||
| // is *much easier* when the _test.v files are very short and focused.
 | ||||
| struct Point { | ||||
| 	x i8 | ||||
| 	y i8 | ||||
| 	z i8 | ||||
| } | ||||
| 
 | ||||
| fn (p Point) draw() string { | ||||
| 	return 'Point($p.x,$p.y)' | ||||
| } | ||||
| 
 | ||||
| fn to_string(d Drawer) string { | ||||
| 	x := d.draw() | ||||
| 	println(x) | ||||
| 	return x | ||||
| } | ||||
| 
 | ||||
| interface Drawer { | ||||
| 	draw() string | ||||
| } | ||||
| 
 | ||||
| fn test_to_string_can_be_called() { | ||||
| 	p := Point{ | ||||
| 		x: 2 | ||||
| 		y: 3 | ||||
| 	} | ||||
| 	res := to_string(p) | ||||
| 	assert res == 'Point(2,3)' | ||||
| } | ||||
|  | @ -0,0 +1,33 @@ | |||
| // The series of i?_test.v files, do test different edge cases for
 | ||||
| // interface table generation. The differences may seem very minor
 | ||||
| // (placement of the interface declaration, whether or not there are
 | ||||
| // helper methods, etc), but PLEASE do NOT be tempted to merge them in
 | ||||
| // a single _test.v file. Debugging interface code generation issues
 | ||||
| // is *much easier* when the _test.v files are very short and focused.
 | ||||
| struct Point { | ||||
| 	x int | ||||
| 	y int | ||||
| 	z int | ||||
| } | ||||
| 
 | ||||
| fn (p Point) draw() string { | ||||
| 	return 'Point($p.x,$p.y)' | ||||
| } | ||||
| 
 | ||||
| fn to_string(d Drawer) string { | ||||
| 	return d.draw() | ||||
| } | ||||
| 
 | ||||
| interface Drawer { | ||||
| 	draw() string | ||||
| } | ||||
| 
 | ||||
| fn test_calling_to_string() { | ||||
| 	p := Point{ | ||||
| 		x: 2 | ||||
| 		y: 3 | ||||
| 	} | ||||
| 	res := to_string(p) | ||||
| 	println(res) | ||||
| 	assert res == 'Point(2,3)' | ||||
| } | ||||
|  | @ -0,0 +1,31 @@ | |||
| // The series of i?_test.v files, do test different edge cases for
 | ||||
| // interface table generation. The differences may seem very minor
 | ||||
| // (placement of the interface declaration, whether or not there are
 | ||||
| // helper methods, etc), but PLEASE do NOT be tempted to merge them in
 | ||||
| // a single _test.v file. Debugging interface code generation issues
 | ||||
| // is *much easier* when the _test.v files are very short and focused.
 | ||||
| struct Point { | ||||
| 	x int | ||||
| 	y int | ||||
| } | ||||
| 
 | ||||
| fn (p Point) draw() string { | ||||
| 	return 'Point($p.x,$p.y)' | ||||
| } | ||||
| 
 | ||||
| fn to_string(d Drawer) string { | ||||
| 	return d.draw() | ||||
| } | ||||
| 
 | ||||
| interface Drawer { | ||||
| 	draw() string | ||||
| } | ||||
| 
 | ||||
| fn test_p_draw_can_be_called() { | ||||
| 	p := Point{ | ||||
| 		x: 2 | ||||
| 		y: 3 | ||||
| 	} | ||||
| 	res := p.draw() | ||||
| 	assert res == 'Point(2,3)' | ||||
| } | ||||
|  | @ -0,0 +1,31 @@ | |||
| // The series of i?_test.v files, do test different edge cases for
 | ||||
| // interface table generation. The differences may seem very minor
 | ||||
| // (placement of the interface declaration, whether or not there are
 | ||||
| // helper methods, etc), but PLEASE do NOT be tempted to merge them in
 | ||||
| // a single _test.v file. Debugging interface code generation issues
 | ||||
| // is *much easier* when the _test.v files are very short and focused.
 | ||||
| struct Point { | ||||
| 	x int | ||||
| 	y int | ||||
| } | ||||
| 
 | ||||
| fn (p Point) draw() string { | ||||
| 	return 'Point($p.x,$p.y)' | ||||
| } | ||||
| 
 | ||||
| interface Drawer { | ||||
| 	draw() string | ||||
| } | ||||
| 
 | ||||
| fn to_string(d Drawer) string { | ||||
| 	return d.draw() | ||||
| } | ||||
| 
 | ||||
| fn test_p_draw_can_be_called() { | ||||
| 	p := Point{ | ||||
| 		x: 2 | ||||
| 		y: 3 | ||||
| 	} | ||||
| 	res := p.draw() | ||||
| 	assert res == 'Point(2,3)' | ||||
| } | ||||
|  | @ -0,0 +1,31 @@ | |||
| // The series of i?_test.v files, do test different edge cases for
 | ||||
| // interface table generation. The differences may seem very minor
 | ||||
| // (placement of the interface declaration, whether or not there are
 | ||||
| // helper methods, etc), but PLEASE do NOT be tempted to merge them in
 | ||||
| // a single _test.v file. Debugging interface code generation issues
 | ||||
| // is *much easier* when the _test.v files are very short and focused.
 | ||||
| struct Point { | ||||
| 	x int | ||||
| 	y int | ||||
| } | ||||
| 
 | ||||
| fn (p Point) draw() string { | ||||
| 	return 'Point($p.x,$p.y)' | ||||
| } | ||||
| 
 | ||||
| fn to_string(d Drawable) string { | ||||
| 	return d.draw() | ||||
| } | ||||
| 
 | ||||
| interface Drawable { | ||||
| 	draw() string | ||||
| } | ||||
| 
 | ||||
| fn test_p_draw_can_be_called() { | ||||
| 	p := Point{ | ||||
| 		x: 2 | ||||
| 		y: 3 | ||||
| 	} | ||||
| 	res := p.draw() | ||||
| 	assert res == 'Point(2,3)' | ||||
| } | ||||
|  | @ -0,0 +1,38 @@ | |||
| // The series of i?_test.v files, do test different edge cases for
 | ||||
| // interface table generation. The differences may seem very minor
 | ||||
| // (placement of the interface declaration, whether or not there are
 | ||||
| // helper methods, etc), but PLEASE do NOT be tempted to merge them in
 | ||||
| // a single _test.v file. Debugging interface code generation issues
 | ||||
| // is *much easier* when the _test.v files are very short and focused.
 | ||||
| interface Drawable { | ||||
| 	draw() string | ||||
| } | ||||
| 
 | ||||
| struct Point { | ||||
| 	x int | ||||
| 	y int | ||||
| } | ||||
| 
 | ||||
| fn (p Point) draw() string { | ||||
| 	return 'Point($p.x,$p.y)' | ||||
| } | ||||
| 
 | ||||
| // Note: this helper function forced the compiler to generate an
 | ||||
| // interface dispatch table. Now, it should not be needed anymore,
 | ||||
| // but it is better to test it too, to prevent future interface regressions.
 | ||||
| fn (x Point) tointerface() Drawable { | ||||
| 	return x | ||||
| } | ||||
| 
 | ||||
| fn to_string(d Drawable) string { | ||||
| 	return d.draw() | ||||
| } | ||||
| 
 | ||||
| fn test_p_draw_can_be_called() { | ||||
| 	p := Point{ | ||||
| 		x: 2 | ||||
| 		y: 3 | ||||
| 	} | ||||
| 	res := p.draw() | ||||
| 	assert res == 'Point(2,3)' | ||||
| } | ||||
|  | @ -0,0 +1,31 @@ | |||
| // The series of i?_test.v files, do test different edge cases for
 | ||||
| // interface table generation. The differences may seem very minor
 | ||||
| // (placement of the interface declaration, whether or not there are
 | ||||
| // helper methods, etc), but PLEASE do NOT be tempted to merge them in
 | ||||
| // a single _test.v file. Debugging interface code generation issues
 | ||||
| // is *much easier* when the _test.v files are very short and focused.
 | ||||
| interface Drawable { | ||||
| 	draw() string | ||||
| } | ||||
| 
 | ||||
| struct Point { | ||||
| 	x int | ||||
| 	y int | ||||
| } | ||||
| 
 | ||||
| fn (p Point) draw() string { | ||||
| 	return 'Point($p.x,$p.y)' | ||||
| } | ||||
| 
 | ||||
| fn to_string(d Drawable) string { | ||||
| 	return d.draw() | ||||
| } | ||||
| 
 | ||||
| fn test_p_draw_can_be_called() { | ||||
| 	p := Point{ | ||||
| 		x: 2 | ||||
| 		y: 3 | ||||
| 	} | ||||
| 	res := p.draw() | ||||
| 	assert res == 'Point(2,3)' | ||||
| } | ||||
		Loading…
	
		Reference in New Issue