Type checking is not working for intermediate variables

[anthony-c-martin]

Repro here:

resource vmWorking 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: 'working'
  location: 'west us'
  properties: {
    // diagnostics raised - we have a property that doesn't make sense.
    valThatDoesNotExist: ''
  }
}

var vmNotWorkingProps = {
  valThatDoesNotExist: ''
}

resource vmNotWorking 'Microsoft.Compute/virtualMachines@2020-06-01' = {
  name: 'notWorking'
  location: 'west us'
  // no diagnostics raised here even though the type is invalid!
  properties: vmNotWorkingProps
}

[majastrz]

Yeah, that's a bad bug. Definitely need to fix that in 0.2.

[anthony-c-martin]

Did some digging on this; it's actually not going to be that simple to fix. In type validation we check for various syntaxes to recurse over:

bicep/src/Bicep.Core/TypeSystem/TypeValidator.cs

Line 168 in 2c5fa92

// object assignability check

We need to ensure we recurse over VariableAccessSyntax, but need to be careful to attach diagnostics to the reference to the variable reference, rather than the variable value itself.

[anthony-c-martin]

We should make sure when we fix this that for the following:

var varWithLiterals = [
  {
    prop: 'ValA'
  }
  {
    prop: 'ValB'
  }
]

Our type system should be able to infer the type of:

varWithLiterals[someIndex].prop

as 'ValA' | 'ValB' (union of string literals) rather than just string.

[anthony-c-martin]

I'm planning to discuss this with the team today - we have some decisions to make about what the errors will look like.

[anthony-c-martin]

Notes from discussion:

• See if we can provide a path to the offending property.
• The error/warning should be shown on the property value, not the property key.
• Each mismatched property should be handled as a separate error/warning unless the prefix for the log is really long.
• We should investigate what newlines in errors/warnings looks like in VSCode hovers & problems window to see if that's viable.
• There are going to be a lot of edge cases. We should start small (e.g. by validating 1 property deep), and expand if necessary.