Parser changes to improve handling of static method calls (#1290)

Static Method Calls
-------------------

The main fix here is for parsing of calls to static methods. Given a type like:

    struct S
    {
        void doThing();
    }

the parser currently gets tripped up on a statement like:

    S::doThing();

The problem here is that the `Parser::ParseStatement` routine was using the first token of lookahead to decide what to do, and in the case where it saw a type name it assumed that must mean the statement would be a declaration.

It turns out that `Parser::ParseStatement` already had a more intelligent bit of disambiguation later on when handling the general case of an identifier (for which it couldn't determine the type-vs-value status at parse time), and simply commetning out the special-case handling of a type name and relying on the more general identifier case fixes the issue.

That catch-all case still has some issues of its own, and this change expands on the comments to make some of those issues clear so we can try to address them later.

Empty Declarators
-----------------

One reason why the static method call problem was hard to discover was that it was masked by the parser allowing for empty declarator. That is, given input like:

    S::doThing();

This can be parsed as a variable declaration with a parenthesized empty declarator `()`.

Practically, there is no reason to support empty declarators anwhere except on parameters, and allowing them in other contexts could make parser errors harder to understand.

This change makes the choice of whether or not empty declarators are allowed something that can be decided at each point where we parse a declarator, and makes it so that only parsing of parameters opts in to allowing them.

By disabling support for empty declarators in contexts where they don't make sense, we make code like the above a parse error when it appears at global scope, rather than a weird semantic error.

A more complete future version of this change might *also* make support for parenthesized declarators an optional feature, or remove that support entirely. Slang doesn't actually support pointers (yet) so there is no real reason to allow parenthesized declarators right now.

One note for future generations is that using an emptye declarator on a parameter of array type can actually create an ambiguity. If the user writes:

    void f(int[2][3]);

did they mean for it to be interpreted as:

    void f(int a[2][3]);

or as:

    void f(int[2][3] a);

or even as:

    void f(int[2] a[3]);

The first case there yields a different type for `a` than the other two, but is also what we pretty much *have* to support for backwards compatibility with HLSL. Requiring all function declarations to include parameter names would eliminate this potentially confusing case.

Layout Modifiers
----------------

One of the above two syntax changes led to a regression in the output for a diagnostic test for `layout` modifiers (which are a deprecated but still functional feature from back when `slangc` supported GLSL input).

The original output of the test case seemed odd, and when I looked at the parsing logic I saw that an early-exit error case was leading to spurious error messages because it failed to consume all the tokens inside the `layout(...)`. Fixing the logic to not use an early-exit (and instead rely on the built-in recovery behavior of `Parser`) produced more desirable diagnosic output.

I changed the input file to put the `binding` and `set` specifiers on differnet lines so that the error output could show that the compiler properly tags both of the syntax errors.

1 files changed, 2 insertions, 2 deletions

diff --git a/tests/bugs/glsl-layout-define.hlsl.expected b/tests/bugs/glsl-layout-define.hlsl.expected
index 9c00916c3..a151f79e9 100644
--- a/tests/bugs/glsl-layout-define.hlsl.expected
+++ b/tests/bugs/glsl-layout-define.hlsl.expected
@@ -1,7 +1,7 @@
 result code = -1
 standard error = {
-tests/bugs/glsl-layout-define.hlsl(3): error 20001: unexpected identifier, expected integer literal
-tests/bugs/glsl-layout-define.hlsl(3): error 20001: unexpected ')', expected ';'
+tests/bugs/glsl-layout-define.hlsl(4): error 20001: unexpected identifier, expected integer literal
+tests/bugs/glsl-layout-define.hlsl(5): error 20001: unexpected identifier, expected integer literal
 }
 standard output = {
 }