ziglang/translate-c
17
125
Fork
You've already forked translate-c
37

Update Aro and Zig #305

Merged
Vexu merged 2 commits from :main into main 2026年03月17日 16:20:03 +01:00
Contributor
Copy link

Translate-C doesn't currently work on Zig master, fix for the issue (std.ArrayList now needs to be initialized as .empty not .{}) was merged in https://github.com/Vexu/arocc/pull/975.

Translate-C doesn't currently work on Zig master, fix for the issue (`std.ArrayList` now needs to be initialized as `.empty` not `.{}`) was merged in [https://github.com/Vexu/arocc/pull/975](https://github.com/Vexu/arocc/pull/975).
Update Aro and Zig
Some checks failed
ci / build (aarch64-macos) (pull_request) Failing after 2m22s
ci / build (x86_64-linux) (pull_request) Failing after 38s
ci / build (x86_64-freebsd) (pull_request) Failing after 1m8s
ci / build (x86_64-windows) (pull_request) Failing after 11m42s
48c2b1c8f5
Author
Contributor
Copy link

The test failure is the result of changes made in zig#31403 where pointer types with explicit alignment are no longer considered equal to otherwise same pointers without explicit alignment (*u8 != *align(1) u8). The type of field alignment in std.builtin.Type.Pointer also changed from comptime_int to ?usize where null means implicit alignment, which is equivalent to @alignOf(child). The fix for this issue is either setting the @"align" in FlexibleArrayType to null:

 /// Constructs a [*c] pointer with the const and volatile annotations
 /// from SelfType for pointing to a C flexible array of ElementType.
 pub fn FlexibleArrayType(comptime SelfType: type, comptime ElementType: type) type {
 switch (@typeInfo(SelfType)) {
 .pointer => |ptr| {
 return @Pointer(.c, .{
 .@"const" = ptr.is_const,
 .@"volatile" = ptr.is_volatile,
 .@"allowzero" = true,
 .@"addrspace" = .generic,
- .@"align" = @alignOf(ElementType),
+ .@"align" = null,
 }, ElementType, null);
 },
 else => |info| @compileError("Invalid self type \"" ++ @tagName(info) ++ "\" for flexible array getter: " ++ @typeName(SelfType)),
 }
 }

or adding explicit alignment to the expected types in FlexibleArrayType test. Let me know which one is preferred.

The test failure is the result of changes made in [zig#31403](https://codeberg.org/ziglang/zig/pulls/31403#the-bad-stuff) where pointer types with explicit alignment are no longer considered equal to otherwise same pointers without explicit alignment (`*u8 != *align(1) u8`). The type of field `alignment` in `std.builtin.Type.Pointer` also changed from `comptime_int` to `?usize` where `null` means implicit alignment, which is equivalent to `@alignOf(child)`. The fix for this issue is either setting the `@"align"` in `FlexibleArrayType` to `null`: ```diff /// Constructs a [*c] pointer with the const and volatile annotations /// from SelfType for pointing to a C flexible array of ElementType. pub fn FlexibleArrayType(comptime SelfType: type, comptime ElementType: type) type { switch (@typeInfo(SelfType)) { .pointer => |ptr| { return @Pointer(.c, .{ .@"const" = ptr.is_const, .@"volatile" = ptr.is_volatile, .@"allowzero" = true, .@"addrspace" = .generic, - .@"align" = @alignOf(ElementType), + .@"align" = null, }, ElementType, null); }, else => |info| @compileError("Invalid self type \"" ++ @tagName(info) ++ "\" for flexible array getter: " ++ @typeName(SelfType)), } } ``` or adding explicit alignment to the expected types in `FlexibleArrayType` test. Let me know which one is preferred.
Member
Copy link

Explicit alignment is not needed.

Explicit alignment is not needed.
Remove explicit alignment from FlexibleArrayType
All checks were successful
ci / build (x86_64-linux) (pull_request) Successful in 5m37s
ci / build (aarch64-macos) (pull_request) Successful in 7m56s
ci / build (x86_64-freebsd) (pull_request) Successful in 4m21s
ci / build (x86_64-windows) (pull_request) Successful in 10m21s
5f16718cb1
Vexu referenced this pull request from a commit 2026年03月17日 16:20:05 +01:00
Sign in to join this conversation.
No reviewers
Labels
Clear labels
bounty
https://ziglang.org/news/announcing-donor-bounties
bug
Observed behavior contradicts documented or intended behavior.
contributor-friendly
This issue is limited in scope and/or knowledge of project internals.
downstream
An issue with a third-party project that uses this project.
enhancement
Solving this issue will likely involve adding new logic or components to the codebase.
infra
An issue related to project infrastructure, e.g. continuous integration.
optimization
A task to improve performance and/or resource usage.
question
No questions on the issue tracker; use a community space instead.
regression
Something that used to work in a previous version stopped working
upstream
An issue with a third-party project that this project uses.
use case
Describes a real use case that is difficult or impossible, but does not propose a solution.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ziglang/translate-c!305
Reference in a new issue
ziglang/translate-c
No description provided.
Delete branch ":main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?