Unhandled exception. System.ArgumentException: Unable to determine parent of specified node of type 'FunctionCallSyntax' at span '[468:520]' because it has not been indexed. #13618
Comments
|
Unfortunately it looks like we don't log enough information to identify which module the problem is occurring in. What I can see from the message is that it's occurring in a grandchild module - e.g. with a structure like: This may not help narrow it down too much, depending on how complex your deployment is. The easiest option I've found to figure out the character position (which doesn't include line numbers) is to select from the start of the file, and look at this in VSCode: If that doesn't help figure out where the problem is, I can add some logging and give you a nightly build to get more detail. |
|
@anthony-c-martin I am not seeing any errors. As in order to reproduce this outside of our environment (as I have already reverted to 0.25) I am using WSL with Ubuntu. I have tried running VSC in WSL mode but I am not getting any errors there. Due to that may be nightly bicep file would be better to try on so I can execute the command instead of opening vsc. |
|
@anthony-c-martin may be I have forgot to mention that the issue does not happen only on one template. It happens on multiple ones. I think all that have user defined schema. I have not tested every one of them but I got reported for at least 3 of them. The one mentioned is just one example. Let me know where I can download this debug bicep cli when ready and I will test to see what it shows. |
|
I've submitted a PR which will trigger a nightly build: #13655. This will add more identifying information to the error to allow us to locate the problematic file + location. If you want to try it in a build pipeline, you should be able to use the nightly install script. Here's a powershell example: # <path_to_binary> here should be replaced with the path to where you want bicep.exe to be installed (e.g. C:\foo\bar would result in C:\foo\bar\bicep.exe)
iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) } -RunId 8329672150 -BinaryPath <path_to_binary>" |
|
@anthony-c-martin I am having trouble doing this. First I cannot do it on Windows as the problem is visible only on Ubuntu. I have tried: but got error as you can see. |
|
Strange... does the following work? gh run download -R Azure/bicep 8329672150 -n "bicep-release-linux-x64" --dir /home/stan
chmod +x /home/stan/bicep
/home/stan/bicep --version |
|
@anthony-c-martin yes. thank you! I think we have the line number. Below is the error generated by the template: |
|
line 14-22. Perfectly normal syntax that we use on many templates. |
|
I believe this is a regression in #13546 with the introduction of this check. @jeskew would you mind taking a look? It would also be good to understand where the nondeterminism (different results on different runs) is coming from - elsewhere we've tried to keep the compilation logic deterministic. |
|
@anthony-c-martin lol. If that is the culprit it is something that I have requested :D. Yeah, it is also strange that it does not errors out on Windows but only on Linux. |
|
I am also facing the same issue in Azur pipelines with Ubuntu agent. I can see only build agent version image got changed as below Succeeded agent Current image version: '20240310.1.0' Please let us know if anybody have any idea on this. |
|
For a temporary workaround, I would recommend manually reverting back to an older version of Bicep. If you're using Azure CLI, you'll need to run the following before running your AzCLI commands to submit the deployment: az bicep install --version v0.25.53 |
jeskew
added a commit
that referenced
this issue
Mar 27, 2024
…13671) 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](https://microsoft.github.io/open-pr/?codeflow=https://github.com/Azure/bicep/pull/13671)
StephenWeatherford
pushed a commit
that referenced
this issue
Apr 1, 2024
…13671) 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](https://microsoft.github.io/open-pr/?codeflow=https://github.com/Azure/bicep/pull/13671)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bicep version
Bicep CLI version 0.26.54 (5e20b29)
Describe the bug
This issue started to appear when we upgraded to 0.26.54 yesterday. We run self-hosted agents on Ubuntu 20.04. Strangely I cannot reproduce this issue on my Windows with same Bicep version but I can reproduce it on WSL Ubuntu 20.04 with bicep 0.26.54 installed. I think issue is also only related to using user defined types.
To Reproduce
main.bicep
config.bicepparam
Error that is produced when we try to do bicep build-params and New-AzSubscriptionDeployment
Additionally I get another PowerShell error when I run with new-azsubscriptiondeployment:
As you can see besides the bicep error I also get: Cannot retrieve the dynamic parameters for the cmdlet.
I do not know if the issues are two or one.
The above reproduction is partial template code without user defined types. If needed I can provide the full template with user defined types in private.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: