Runtime error when referencing property which is a number

[afscrome]

Bicep version
Bicep CLI version 0.4.613 (d826ce8)

Describe the bug

The following template compiles successfully, but fails with a deployment error:

targetScope = 'subscription'

var map = {
    '1': 'hello'
}

output one string = map['1']

But it fails at deployment time with the following error:

{
  "error": {
    "code": "InvalidTemplate",
    "message": "Deployment template language expression evaluation failed: 'Unable to parse language expression 'variables('map').1': expected token 'Identifier' and actual 'Integer'.'. Please see https://aka.ms/arm-template-expressions for usage details.",
    "additionalInfo": [
      {
        "type": "TemplateViolation",
        "info": {
          "lineNumber": 0,
          "linePosition": 0,
          "path": ""
        }
      }
    ]
  }
}

Additional context

The bug appears to be with the bicep compiler incorrectly translating map['1'] to [variables('map').1]. It should be converted to [variables('map')['1']]

[anthony-c-martin]

Good find, thanks for reporting!

[anthony-c-martin]

I did some investigation here - it's actually an issue with the expression serialization/parsing library that we use from the Deployments library, rather than the Bicep code.

• The serializer generates [variables('map').1]
• The tokenizer converts 1 into an Integer token
• The parser doesn't expect to see an Integer token after a . as it is only expecting an Identifier token

I think there are two possible fixes:

1. Modify the serializer to check whether the property access value is fully numeric, and if so, instead serialize it to[variables('map')['1']]
2. Modify the parser to be able to handle an Integer token immediately after a ., and treat it as if it were an Identifier.

[majastrz]

I don't think you can do option 2 because array indexing is represented by having a JValueExpression of long type in Properties of a FunctionExpression. If we also represent string indexing of an object with a property name that happens to be a numeric string, it'll be ambiguous.

I think the only option is option 1. (I assume by checking if "fully numeric" you mean checking it matches the parser rules.)