Distinguish between type syntax vs expression syntax in the parser

[jeskew]

Resolves #13618

In order to make type determinations, the DeclaredTypeManager needs to know whether it is within type syntax or expression syntax. This distinction is meaningful for property access (e.g., <array type>[*] is legal within type syntax but not within expression syntax, whereas <array value>[?0] is legal within expression syntax but not within type syntax), variable access (variables within type syntax can refer to other types but not values, and variables within expression syntax can refer to values but not types), nullability control syntax, and literal value syntax.

Prior to Bicep 0.26, the type manager was relying on internal state that assumed the AST would be visited in order. This resulted in unstable type assignments if the type of type syntax was requested out of order. In Bicep 0.26.54, this was replaced with a deterministic check that used the model's syntax hierarchy to determine whether a given syntax node was a descendant of the type declaration of an output or parameter statement or the assigned value of a type statement (indicating type syntax) or not (indicating expression syntax). However, querying the syntax hierarchy can throw an exception if a node was not part of the original model (e.g., if it was created by a SyntaxRewriteVisitor).

This PR moves the responsibility for making this distinction to the parser. The parser is already tracking whether it is within type syntax or expression syntax, as the grammar for each syntax class is distinct. This PR introduces some new descendent classes of TypeSyntax that are minimally changed copies of descendent classes of ExpressionSyntax: VariableAccessSyntax is a descendent of ExpressionSyntax, and TypeVariableAccessSyntax is a descendent of TypeSyntax, but the two classes are otherwise identical. This means that the compiler can determine whether an arbitrary syntax node was encountered in type syntax or expression syntax based solely on the C# type of the syntax node rather than having to rely on the syntax hierarchy or order of operations.

About 50% of the line count for this PR comes from baseline changes. These are all to the main.syntax.bicep artifacts and consist of the class name for specific nodes being changed (e.g., VariableAccessSyntax -> TypeVariableAccessSyntax, StringSyntax -> StringTypeLiteralSyntax, etc.).

Microsoft Reviewers: Open in CodeFlow

[github-actions]

Test this change out locally with the following install scripts (Action run 8458462785)

VSCode

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-vsix.sh) --run-id 8458462785

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) } -RunId 8458462785"

Azure CLI

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-cli.sh) --run-id 8458462785

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) } -RunId 8458462785"

[github-actions]

Test Results

    66 files   -     33      66 suites   - 33   22m 37s ⏱️ - 22m 31s
10 719 tests  -     20  10 717 ✅  -     20  2 💤 ±0  0 ❌ ±0 
25 334 runs   - 12 663  25 330 ✅  - 12 661  4 💤  - 2  0 ❌ ±0 

Results for commit d9083ef. ± Comparison against base commit 6f3a864.

[majastrz]

private

Do we also need to make updates to the grammar.md pseudo grammar file?

[jeskew]

The grammar isn't changing, just the AST. So where previously we would have always used IntegerLiteralSyntax, we now use IntegerLiteralSyntax in a value expression and IntegerTypeLiteralSyntax in a type expression. That way there's no ambiguity later in the compilation process as to whether this syntax node was part of a type or a value.

[majastrz]

[shenglol]