v3: fold imported const aliases in fixed-array lengths

[antono3]

Summary

V3 can leave an imported const alias in a fixed-array length, such as [vk.max_extension_name_size]char, as a C identifier vk__max_extension_name_size. That identifier has no C declaration, so the generated C fails. Resolve the import alias to its module const before evaluating the array length. When the same alias refers to different modules in different files, leave it unresolved rather than guessing.

Reduced reproducer

// module fixture
pub const max_name_size = u32(256)

// main.v
import fixture as fx
fn name_size(name [fx.max_name_size]char) int { return name.len }
fn main() { println(name_size([fx.max_name_size]char{})) }

Before this change, V3 C compilation fails on an undeclared fx__max_name_size. This pattern appears in the current Vulkan ImGui example as [vk.max_extension_name_size]char.

Validation

• ./v self
• ./v fmt -w on both touched files
• Full ./v -silent test vlib/v/compiler_tests/fixed_array_typedef_codegen_test.v (pass)
• Focused regression rerun after final edit (pass)
• Reduced standalone Vulkan-style alias reproducer compiles and runs.

I attempted VJOBS=3 ./v -silent test vlib/v/types/; the unrelated ownership test could not find a writable compiler cache, so I stopped that broad run after the environment failure.

This is independent of the enum callback typedef work in #28902.

Current-master verification (2026-09-26)

Rebased onto 6c359c228241b44f9d9a942696e83b513931e532. The focused regression passes with strict V3 (-new-compiler). The same regression fails on unmodified master, confirming the fix remains necessary. Formatting verification for all changed V files and git diff --check pass. The previously failing twelve formatter files pass on this master. The unrelated anon_struct_cross_module_init_test.v still fails on unmodified master (the genuinely anonymous parameter case); this refresh does not change it.

[medvednikov]

@codex review

[medvednikov]

Reviewed 760529f, including the parser's comment-free selector reconstruction and the constant candidate ordering. The added fixture covers one alias colliding with a real module, but the documented conservative behavior for aliases with multiple meanings is not enforced by the caller; see the inline comment.

This is a source review; I have not executed a compiler build or the regression tests in this environment.

[medvednikov]

@codex review

[medvednikov]

Re-reviewed current head 0253bb00c22fbe6ca7131f2a4c5b59a021b30ff6 for the earlier ambiguous-import-alias P2.

That finding is addressed. The alias lookup now returns an explicit ambiguity flag, and const_int_value_in_module returns none before trying the real-module/name/suffix candidates when the alias has conflicting meanings. A unique alias is tried before a homonymous real module. The unit tests use distinct lengths (256, 128 and 16), cover repeated consistent imports and an unaliased module control, and the compiler regression requires the ambiguous program to fail with a non-constant-bound diagnostic instead of silently choosing 16. Parsed selector names also avoid carrying comments into the stored bound spelling.

The documented limitation is still intentional: stored types without sufficient source-file context reject conflicting per-file aliases rather than resolving each file independently. I found no additional concrete issue in this focused follow-up review. Static source/test review only; I did not execute the regressions or use CI results.

[medvednikov]

@codex review