Introduce an unresolved flag in ast.TypeFlag

[kbkpbot]

The current flags in TypeFlag are as follows:

// max of 8
pub enum TypeFlag as u32 {
	option             = 1 << 24
	result             = 1 << 25
	variadic           = 1 << 26
	generic            = 1 << 27
	shared_f           = 1 << 28
	atomic_f           = 1 << 29
	option_mut_param_t = 1 << 30
}

Can it be expanded to:

// max of 8
pub enum TypeFlag as u32 {
	option             = 1 << 24
	result             = 1 << 25
	variadic           = 1 << 26
	generic            = 1 << 27
	shared_f           = 1 << 28
	atomic_f           = 1 << 29
	option_mut_param_t = 1 << 30
	unresolved         = 1 << 31 // for unresolved type
}

I'm currently facing a tricky issue in the development a PR to support Feature requested by #25183.

In the original code, fixed-length array types are registered in the parser using find_or_register_array_fixed(). However, during the parse stage, due to incomplete information (such as const variables in other files), it's impossible to correctly resolve all constant expressions size_expr in [size_expr]int{}.

My approach is to register an array type during the parser stage using find_or_register_array_fixed_unresolved_size(elem_type Type, size_expr Expr, is_fn_ret bool, mod_name string). Then, during the checker stage, after obtaining sufficient information, resolve the size_expr for all fixed-length array types in type_symbols, and then call find_or_register_array_fixed_with_size(elem_type Type, size int, is_fn_ret bool) to register the new array type.

The problem now is that multiple different fixed-length arrays from the parser stage may resolve to the same fixed-length array. For example, in module main:

During the parser stage, two fixed-length arrays [a]int{} and [b]int{} are registered. Since the values of a and b are unknown at this stage, they are registered as different array types (let's say types 123 and 124).

However, during the checker stage, after resolution, it's discovered that a = b = 2. Thus, both should map to the same fixed-length array [2]int{}(let's say type 200).

As a result, the system now has three fixed-length array types: 123, 124, and 200. But in reality, they should all be type 200.

This causes issues in many parts of the checker and cgen code. For example, in an assignment statement, the type is determined as 123 during the parser stage. If checker or cgen uses 123 for type checking or code generation, errors occur. The correct approach is to use type 200 for checking and code generation.

By introducing an unresolved type flag in TypeFlag and a type redirection mechanism, this issue can likely be solved. For example, we can introduce a map[int]int in the table to implement mapping from unresolved types to resolved types. At every point where type information is needed, we must check whether redirection is required.

Another approach is to traverse the entire AST and replace all types after resolving all unresolved types.

Or there is a better way to solve this problem?

BTW, the current space in TypeFlag seems insufficient.

[kbkpbot]

Other ideas:

-Expand Type from u32 to u64 to provide sufficient space for flags;

-Provide a method to fully traverse the AST;

-Introduce a new stage between the parser and checker, perhaps called "resolve type"?

[Delta456]

We already have a transformer stage between parser and checker.

[felipensp]

Have you seen Checker.update_unresolved_fixed_sizes()?

[kbkpbot]

Yes, but it only fix function return and alias.
I still think about how to solve this problem.