Nested structs are not well supported

[kopecs]

Describe the bug

Nested structs should have the same level of support as other fields, but are currently displayed just as nameless offsets, or result in a crash.

To Reproduce
See attached code.

Expected behavior
Structs should be displayed the same as all other fields, and valid code should not crash

Screenshots
If applicable, add screenshots to help explain your problem.

Code being executed

Struct containing a struct

struct X { int x; };

struct Y {
    int foo;
    struct X x;
};

int main() {
    struct Y* a = alloc(struct Y);
    a->foo = 1;
    a->x.x = 2;
    return 0;
}

Array of structs

struct X { int x; };

struct Y {
    int foo;
    struct X x;
};

int main() {
    struct Y[] a = alloc_array(struct Y, 10);
    a[0].foo = 3;
    a[0].x.x = 0;
    a[1].foo = 5;
    return 0;
}

Additional context
Not super high prio, but the crashing is not good.

[MarkChenYutian]

Oh no. It seems that I've made some false assumption on how C0 type works. When writing debugger, I assumed that all structs are behind a pointer.

When the code above executes, the assumption above is violated and the debugger crashes.

Will try to manage this during the fall break.

[MarkChenYutian]

Turns out this bug is related with some core definition of type representation in VM. Current definition of C0Type does not support a "naked struct":

C0VM-ts/src/types/c0types.d.ts

Lines 7 to 28 in 504e6a2

	type C0Type<T extends C0TypeClass> =
	T extends "value" ? {
	type: T,
	value: C0ValueTypes
	} :
	T extends "ptr" ? {
	type: T,
	kind: "arr"| "ptr", // "arr" -> "C[]", "ptr" -> "C*"
	value: C0Type<C0TypeClass>, // the type "C" in comment above
	} | {
	type: T,
	kind: "struct",
	value: string, // If a pointer points to the struct, we record the
	offset: number // struct type name and offset
	} :
	T extends "string" ? {
	type: T,
	value: "string"
	} :
	T extends "<unknown>" ? {
	type: T // No more type information for unknown
	} : never;

This can't be fixed easily without re-writing most of the type inference. I'll rewrite and clean up the type inference in current codebase during winter break. And hopefully by that time this will be fixed.