Aro translate-c

[Vexu]

This starts work on #16268. None of it is tested currently so I'll need to update the test harness before this is contributor friendly.

[kubkon]

Very exciting!

[andrewrk]

For maintaining Aro, I think we should pick one of these options:

• Put Aro in src/, don't mark it as vendored, allow tight coupling with other compiler code, and periodically port code back and forth between the Zig source tree and the Aro source tree. This is @kubkon's current strategy for zld.
• Start maintaining Aro in the zig source tree itself; archive the external Aro project.
• Merge Support relative paths in package manager #14603, continue maintaining Aro separately, use deps/, mark the files as vendored, have a policy of no downstream patches, and use Aro via @import("aro") using the public Aro API only.

Up to you, @Vexu. What do you prefer?

[Vexu]

I was planning on going with option 3.

[andrewrk]

Sounds great 👍

[andrewrk]

So, what's the transition plan? For now, enable it only when -Denable-llvm=false?

[Vexu]

That's what it does currently:

// Make a decision on whether to use Clang or Aro for translate-c and compiling C files.
const c_frontend = blk: {
    if (!build_options.have_llvm) break :blk .aro;
    if (options.c_frontend) |explicit| break :blk explicit;
    break :blk .clang;
};

[Vexu]

Not sure what the CI failure is caused by. I can't reproduce it locally with zig build.

[ianprime0509]

I believe the CI failure is because zig2 doesn't have any of the package management code included in it, including path-based dependencies (

zig/src/main.zig

Lines 4798 to 4803 in 3031819

	const deps_pkg = try Package.createFilePkg(gpa, local_cache_directory, "dependencies.zig",
	\\pub const packages = struct {};
	\\pub const root_deps: []const struct { []const u8, []const u8 } = &.{};
	\\
	);
	try main_pkg.add(gpa, "@dependencies", deps_pkg);

). I can also reproduce this when building from scratch starting from CMake.

[andrewrk]

Yes I'm sorry, after I mentioned #14603 above, I realized it wasn't actually going to work exactly that way because we want to avoid all that machinery while bootstrapping. I think it will be fine just adding logic to build.zig instead for integration. I think you had it that way in the first place anyway.

[andrewrk]

Everything looks great and ready to merge, except I have one request-

[andrewrk]

I think using CFrontend internally is a good idea, however, as for the CLI, I don't think zig ever plans to have more options for C frontends. The plan is:

• (now) support clang and aro
• (future) support aro only

I think -fclang and -fno-clang is nice since it is very similar to the llvm and lld flags above, and all 3 sets of flags will disappear together one day.

Do you have a strong preference for -c-frontend? I would prefer keeping the CLI as -fclang and -fno-clang.

[Vexu]

No preference, -fclang/-fno-clang works for me.

[andrewrk]

Nice! In that case, feel free to proceed with the merge after making that change 👍