closure: add sparc64 support

[tankf33der]

The entire foundation for sparc64 is already in master.
Now we need to enable closure support.
Already verified the patch manually on sparc64, everything is ok:

tankf33der@cfarm202:~/v$ VTEST_ONLY=closure ./v test vlib/
---- Testing... ----------------------------------------------------------------------------------------------------------------------------
 OK    [ 1/31] C:  4602.1 ms, R:    10.020 ms vlib/v/tests/fns/closure_variable_in_smartcast_test.v
 OK    [ 2/31] C:  4692.9 ms, R:    10.976 ms vlib/v/tests/builtin_arrays/array_ops_create_just_one_closure_test.c.v
 OK    [ 3/31] C:  4951.7 ms, R:     9.680 ms vlib/v/tests/fns/closure_data_with_gc_test.c.v
 OK    [ 4/31] C:  4954.0 ms, R:     9.526 ms vlib/v/tests/fns/closure_with_fixed_array_var_test.v
 OK    [ 5/31] C:  4968.2 ms, R:     9.539 ms vlib/v/tests/builtin_arrays/array_filter_using_direct_closure_test.v
 OK    [ 6/31] C:  5006.1 ms, R:     8.152 ms vlib/v/tests/arrays_closure_fixed_array_test.v
 OK    [ 7/31] C:  5023.6 ms, R:     7.561 ms vlib/v/tests/generics/generics_closure_fn_direct_call_test.v
 OK    [ 8/31] C:  5025.3 ms, R:     8.026 ms vlib/v/tests/generics/generics_return_closure_test.v
 OK    [ 9/31] C:  5081.4 ms, R:     9.256 ms vlib/v/tests/generics/generics_closure_fn_test.v
 OK    [10/31] C:  5107.9 ms, R:     8.185 ms vlib/v/tests/fns/closure_test.v
 OK    [11/31] C:  5119.3 ms, R:     6.565 ms vlib/v/tests/generics/return_closure_f64_test.v
 OK    [12/31] C:  5122.2 ms, R:     7.142 ms vlib/v/tests/fns/closure_of_instance_method_passed_to_voidptr_parameter_test.v
 OK    [13/31] C:  5133.1 ms, R:     6.789 ms vlib/v/tests/fns/closure_of_method_defined_on_alias_test.v
 OK    [14/31] C:  5138.8 ms, R:     6.383 ms vlib/v/tests/fns/closure_in_if_guard_1_test.v
 OK    [15/31] C:  5141.2 ms, R:     5.894 ms vlib/v/tests/fns/closure_fn_arg_in_map_test.v
 OK    [16/31] C:  5146.7 ms, R:     5.804 ms vlib/v/tests/fns/closure_in_if_guard_2_test.v
 OK    [17/31] C:  5155.0 ms, R:     6.515 ms vlib/v/tests/match_multi_return_closure_heap_test.v
 OK    [18/31] C:  5167.0 ms, R:     6.978 ms vlib/v/tests/assign/assign_literal_with_closure_test.v
 OK    [19/31] C:  5169.1 ms, R:     6.373 ms vlib/v/tests/comptime/comptime_call_method_closure_test.v
 OK    [20/31] C:  5171.1 ms, R:     5.851 ms vlib/v/tests/closure_with_fn_ref_var_test.v
 OK    [21/31] C:  5188.8 ms, R:     7.487 ms vlib/v/tests/fns/anon_c_keywords_closure_test.v
 OK    [22/31] C:  5192.0 ms, R:     6.569 ms vlib/v/tests/interfaces/interface_closure_test.v
 OK    [23/31] C:  5197.6 ms, R:     5.147 ms vlib/v/tests/interfaces/interface_method_closure_test.v
 OK    [24/31] C:  5209.0 ms, R:     4.833 ms vlib/v/tests/fns/closure_option_direct_call_test.v
 OK    [25/31] C:  5215.6 ms, R:     4.077 ms vlib/v/tests/comptime/comptime_closure_field_access_test.v
 OK    [26/31] C:  5213.2 ms, R:     4.179 ms vlib/v/tests/generics/generics_closures_with_different_generic_types_test.v
 OK    [27/31] C:  5220.3 ms, R:     4.211 ms vlib/v/tests/generics/return_closure_int_test.v
 OK    [28/31] C:  5278.6 ms, R:     5.813 ms vlib/v/tests/fns/go_call_anon_fn_with_closure_test.v
 OK    [29/31] C:  5288.1 ms, R:     3.957 ms vlib/v/tests/fns/closure_with_sumtype_var_test.v
 OK    [30/31] C:  6291.1 ms, R:     4.702 ms vlib/v/tests/fns/closure_struct_init_cov_regression_test.v
 OK    [31/31] C:  5386.1 ms, R:  7922.458 ms vlib/v/tests/fns/closure_generator_test.v
--------------------------------------------------------------------------------------------------------------------------------------------
Summary for all V _test.v files: 31 passed, 31 total. Elapsed time: 13358 ms, on 31 parallel jobs. Comptime: 159557 ms. Runtime: 8128 ms.
tankf33der@cfarm202:~/v$ uname -a
Linux cfarm202 6.17.0-rc5+ #1 SMP Fri Sep 12 20:37:32 UTC 2025 sparc64 GNU/Linux
tankf33der@cfarm202:~/v$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux forky/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=forky
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0acd84d57d

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Add the missing comma in sparc64 get-data bytecode

The new closure_get_data_bytes branch has a malformed array element list: u8(0x91) 0xb0 is missing a comma between bytes, so the thunk byte table is not valid V syntax. This causes compilation to fail when the sparc64 branch is parsed/selected (e.g. building on sparc64), blocking the architecture support this commit is trying to add.

Useful? React with 👍 / 👎.

[JalonSolov]

Incorrect. V does not require commas between data elements in an array.

It would be good for the array to be consistent, but is not required.

[tankf33der]

Good catch, fixed.

[JalonSolov]

At least one error related to this change:

native error: /home/runner/work/v/v/vlib/v/gen/native/comptime.v:232, &native.Gen{}.comptime_ident Unhandled os ifdef name "sparc64".

[JalonSolov]

One other thing that just hit me... in the other, related PR, we saw that sparc is 64-bit sparc, so there's no real need for 64 on the end.

Just as there's no need for ppc64be when ppc64 means big-endian.

I don't know if it is worth changing that now, just brought it up now that I thought of it.

[tankf33der]

One other thing that just hit me... in the other, related PR, we saw that sparc is 64-bit sparc, so there's no real need for 64 on the end.

Just as there's no need for ppc64be when ppc64 means big-endian.

I don't know if it is worth changing that now, just brought it up now that I thought of it.

I have an idea about what might have confused you — one is the name of a define variable, the second is the name of an architecture or Fujitsu CPU product name SPARC64.
The correct short name for the architecture family is sparc64, and I use it. This is a correct and well-established name in IT.
I used it in the same sense as I will use ppc64.

For me, sparc64 sounds like this — 64-bit SPARC. $if sparc {...} will confuse or might confuse the user even more because it covers a family of CPUs not architecture.

@JalonSolov - Did I confuse you even more? :)

Maybe someone else has their own opinion?

[JalonSolov]

As long as that is the "common" name, it is fine. As I said, I don't do sparc. :-)