Support for zig-cc and zig-c++

[lars18th]

Add support to call the binary with "zig-cc" and "zig-c++" names. This will trigger the same as calling with "zig cc" and "zig-c++".

[jedisct1]

See #8973

[mlugg]

This PR implements the rejected proposal #8716. It's also immediately obvious that it would fail CI, but that's a moot point: this functionality is explicitly not something we want.

[lars18th]

Hi @jedisct1 ,

See #8973

I've readed this several time ago. And this patch is not refusing anything discussed on this thread.

Hi @mlugg ,

This PR implements the rejected proposal #8716. It's also immediately obvious that it would fail CI, but that's a moot point: this functionality is explicitly not something we want.

Why you say "It's also immediately obvious that it would fail CI"? You've reviewed the patch? This patch doesn't change anything! The current behaviour continues exactly as it's now. All CI checks will continue running without troubles.

This patch only handles one special case: if the basename of the binary is zig-cc, in this case, and only in this case (the same for zig-c++) the command line parameters is increased with one more item. The new item will be in the position 1 and all others are rotated one position to the right. And the item is cc. Therefore if you call zig-cc param1 param2 ... the code parses zig-cc cc param1 param2 .... Where is the problem?

[mlugg]

Why you say "It's also immediately obvious that it would fail CI"?

CI would immediately fail due to this code not conforming to zig fmt.

If you had included any kind of test coverage for this change, there would also have been a failure due to the unconditional calls to std.log.info in the added case.

This patch doesn't change anything!

That's very clearly not true. This patch changes how the zig binary behaves if argv[0] is anything other than zig.

Where is the problem?

The problem is that this proposal is rejected; the Zig project does not want to include this functionality.

---

Also, note that your code, while not buggy, contains several minor errors:

• As mentioned above, std.log.info should never be called on non-debug success paths.
• Using std.mem.rotate introduces an O(N) operation for absolutely no reason; just assign things correctly in your for loop.
• The arena.free call is redundant; that's the whole point of an arena.