parser: detect mismatched/misleading indentation

[hryx]

Closes #35. This is a follow-up to #13593, which explains some of the design choice rationale.

I added two compile error tests, one for each of the new kinds of error. If the errors were "recoverable" it could be done in one, but I need to study parse.zig more to understand how to make parse errors recoverable. Let me know if that's desirable.

I found a TODO in parser_test.zig (added in 79f1876) which suggests that a fix to #35 should allow for a particular recoverable error scenario with closing curly braces. I don't 100% understand the expectation, so please let me know what it means if it is still a relevant blocker.

[Jarred-Sumner]

Does zig fmt continue to format incorrectly indented code?

[hryx]

@Jarred-Sumner zig fmt will continue to format code when there isn't a parse error.

Summary of the new parse error: Statements within a block must begin at the same indentation level, otherwise error; statements contiguous on one line are unaffected; decls are unaffected. The number of spaces used for an indentation level doesn't matter, only that the indentation is consistent for statements within a block.

test {
             cabbage();        // ok
             barn(             // ok
       1, 2, 3); dad();        // ok
           lasagne();          // error
}

As before, zig fmt will not be able to format code when there is a parse error, like the above example. The new error is in the same category as mismatched whitespace around infix operators like a -b. But using --autofix would effectively enable the existing, forgiving behavior.

There's more detail about the new behavior and rationale in #13593, and the new tests give a taste of what can be parsed and what can't.

[Jarred-Sumner]

Statements within a block must begin at the same indentation level, otherwise error

Shipping this without making zig fmt automatically fix indentation & spacing-related issues by default is a big mistake, imo. Most of what zig fmt does is fix spacing & indentation-related mistakes. It means developers writing Zig don't have to think about spacing and newlines as much. That is important for productivity.

I have no say in whether or not this ships, but please don't ship this without zig fmt having it autofix this by default

[andrewrk]

@hryx I have taken the next step to getting this merged, which is to open #17584. I think that new proposal is a prerequisite to #35 as well as your implementation here. I'm going to close this PR in order to keep the queue reserved for patchsets that are ready to land, but if you don't mind, please keep this branch alive in your zig fork, and we can revive it when the time comes.

[hryx]

Understood! Sounds like a good path forward.