This introduces {'} to indicate escape for a single-quoted string,
and {} to indicate escape for a double quoted string.
Without this, there would be unnecessary \' inside double quoted
strings, and unnecessary \" inside single quoted strings.
Motivated by the llvm12 branch, in the new tool I am writing for
updating target CPU features.
This is an accident from a merge conflict introduced in
7edb204edfa41e11776ac009da5a20fb1c907f5f.
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 bf642204b373e01314ecfb0c50a643dc4b05746f 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.
