decoder: Introduce `ValidateFilePerSchema()`

[radeksimko]

As mentioned in hashicorp/terraform-ls#563 it would be helpful for users to have on-type and/or on-save diagnostics based on the schema.

In Terraform specifically this can be achieved via terraform validate, but that comes with a trade-off in the form of loading all plugins and gRPC chattery with all of them to validate the whole configuration.

While the decoder will never be able to run ValidateFuncs declared within providers, it has most of the other context in the form of schema and so it can do most of the early validation on its own.

Known High-Value Use Cases

• empty labels (e.g. resource "" "name" {)
• invalid labels - Different semantic token types for unwanted labels terraform-ls#804
• invalid references - Different semantic tokens for invalid references terraform-ls#805

Before doing anything beyond the basics above in Terraform specifically we may want to address hashicorp/vscode-terraform#715 + hashicorp/terraform-ls#193 to generally be sure the schema can represent the reality accurately and we can avoid publishing false diagnostics just because we don't have accurate schema.

Proposal

• Introduce a Validate method in the hcl-lang decoder package that iterates over the module files

func (d *PathDecoder) Validate(ctx context.Context) (hcl.Diagnostics, error)

• Introduce a ValidateFile method in the hcl-lang decoder package

func (d *PathDecoder) validateFile(ctx context.Context, f *hcl.File) (hcl.Diagnostics, error)

• Obtain the file contents and schema from the PathDecoder
• Only validate HCL files (not JSON)
• Introduce a helper (skeleton) method for validating the file against the schema

func (d *PathDecoder) validateBodyPerSchema(ctx context.Context, body *hclsyntax.Body, bodySchema *schema.BodySchema) (hcl.Diagnostics, error)

• Introduce a helper (skeleton) method that validates references (based on targets and origins)
• Add test files

---

Part of hashicorp/vscode-terraform#720

[radeksimko]

While reimplementing the entirety of terraform validate will likely take time, even if we only focus on what we know from the (JSON) schema, but we can start with just some essential validation.

This is important especially because in terraform-ls we always attempt to obtain the schema via terraform providers schema -json which will fail if the config is not valid.

@jpogran specifically mentioned that a common problem is likely to be an empty label, such as

resource "" "name" {

}

[radeksimko]

One thing to consider while implementing the "essential" validation is that specifically in Terraform LS the provider part of schema may not be accurate as a result of us embedding latest schemas at build time which may not match what provider versions user is actually using.

Therefore I'd probably avoid validating required attributes and other provider-version-sensitive stuff until/unless we address hashicorp/terraform-ls#193

Label requirement is something that will likely almost never change though, so that may be safe to do.

[radeksimko]

Nitpick: I think the second method being proposed should probably be called validateBodyPerSchema given that the argument is no longer a whole file, but just AST body.

func (d *PathDecoder) validateBodyPerSchema(ctx context.Context, body *hclsyntax.Body, bodySchema *schema.BodySchema) (hcl.Diagnostics, error)