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.
After #35 is implemented,
we should be able to recover from this *at any indentation level*,
reporting a parse error and yet also parsing all the decls even
inside structs. Until then, I don't want to add any hacks to make
this work.
I don't understand the idea here of this kind of recovery. If we
want to resurrect this test case we need some comments on it to explain
the purpose, example use cases, expected behavior, etc.
Allowing same line doc comments causes some ambiguity as to how
generated docs should represent the case in which both same line
and preceding line doc comments are present:
/// preceding line
const foobar = 42; /// same line
Furthermore disallowing these makes things simpler as there is now only
one way to add a doc comment to a decl or struct field.
Conflicts:
* lib/std/zig/ast.zig
* lib/std/zig/parse.zig
* lib/std/zig/parser_test.zig
* lib/std/zig/render.zig
* src/Module.zig
* src/zir.zig
I resolved some of the conflicts by reverting a small portion of
@tadeokondrak's stage2 logic here regarding `callconv(.Inline)`.
It will need to get reworked as part of this branch.
