Conflicts:
* src/clang.zig
* src/llvm.zig
- this file got moved to src/llvm/bindings.zig in master branch so I
had to put the new LLVM arch/os enum tags into it.
* lib/std/target.zig, src/stage1/target.cpp
- haiku had an inconsistency with its default target ABI, gnu vs
eabi. In this commit we make it gnu in both places to match the
latest changes by @hoanga.
* src/translate_c.zig
This is an accident from a merge conflict introduced in
7edb204edf.
The new pipe2 code I believe is supposed to work for all posix-like
systems. If haiku needs special handling here, it should be
re-introduced.
* no isHaiku() function since there is not more than one os tag that
this applies to.
* clean up some control flow into a switch
* add some TODO comments to investigate panics that suspiciously look
like they should be compile errors (see #363)
Reverts bf642204b3 and uses a different
workaround, suggested by @LemonBoy.
There is either a compiler bug or a design flaw somewhere around here.
It does not have to block this branch, but I need to understand exactly
what's going on here and make it so that nobody ever has to run into
this problem again.
This regresses the test case of `zig fmt` deleting empty line comments.
Two open questions here:
* What should the rules be about deleting empty line comments?
It makes sense usually, but for array initization, empty line
comments cause a line break, affecting the row/column alignment.
Perhaps we should therefore respect all empty line comments?
Or should we special case array initializations?
* If we decide to special case some kinds of line comments to respect
them (which is status quo!), how should that be implemented?
I modified this test case to expect different results.
Now, the trailing comma on a list of struct fields is the only deciding
factor, not whether or not the field init expressions contain a newline.
Achieve this by reducing the amount of special casing to handle EOF so
that the already correct logic for normal comments does not need to be
duplicated.
