I see type constraint values might still not be supported? So

data"coder_parameter""test" {type=string// Not allowedtype="string"// is allowed

It treatsstring as a reference, rather than a type constraint. This does check out though, as type constraints are treated as keywords. And keywords in expressions are just traversals.

See traversal to keyword:https://github.com/hashicorp/hcl/blob/main/traversal_for_expr.go#L70-L127
And how they parse the keyword to a type:https://github.com/hashicorp/terraform/blob/main/internal/stacks/stackconfig/typeexpr/typeexpr.go#L27-L31

And on the input value:https://github.com/hashicorp/terraform/blob/main/internal/stacks/stackconfig/input_variable.go#L20-L21 (var blocks are input variables)

So type constraints are just references. We might have to keep our types as quoted strings? 😢

Traversals less than 2 are considered invalid too? I am not sure where this error is raised, but it is raised somewhere by the tests. I do see where this is enforce in tflint, which I assume has some parity with terraform.

A reference to a resource type must be followed by at least one attribute        access, specifying the resource name.

TFLint:https://github.com/terraform-linters/tflint-plugin-sdk/blob/master/terraform/addrs/parse_ref.go#L231

Traversals less than 2 are considered invalid too?

I think that's just for a resource, which is alwaysresource_type.name. SeeparseRef for other kinds of traversalshttps://github.com/terraform-linters/tflint-plugin-sdk/blob/master/terraform/addrs/parse_ref.go#L66

Another issue with the current sdk.

#123

The current does not support pointer types? So we have to compute some helper fields?

Relevent:coder/preview#94