Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
hclsyntax: Improve conditional type mismatch errors (somewhat)
For a long time now we've had a very simplistic error message for the case of conditional expression result arms not having the same type, which only works for situations where the two types have differing "friendly names" down in the cty layer. Unfortunately due to the typical complexity of the structural type kinds (object and tuple types) their friendly names are just "object" and "tuple", which tends to lead us to seemingly-incorrect error messages like: The true and false result expressions must have consistent types. The given expressions are object and object, respectively. This then is an attempt to use some more specialized messaging in some of the situations that led to that sort of weird message before. In particular, this handles: - both types are object types but their attributes don't match - both types are tuple types but their elements don't match - both types are the same kind of collection of either object or tuple types which don't match These are the three _shallow_ cases that the previous logic wasn't able to properly describe. This still leaves unaddressed a hopefully-less-common case of nested collections with differing structural types in their depths, but still avoids generating a confusing error message by instead generating a _very vague but still correct_ error message: At least one deeply-nested attribute or element is not compatible across both the 'true' and the 'false' value. My intent here is to make HCL return something precise enough _most of the time_, without letting perfect be the enemy of the good. This will generate some quite obnoxious long messages for particularly complex nested structures, but so far it appears that such values are relatively rare inside conditional expressions and so we'll wait to see what arises in practice before trying to handle those situations more concisely. Ideally I would like to include some actionable feedback that in some cases it can help to explicitly convert ambiguously-typed expressions like "null" or tuples intended to be lists to the intended type, so that the type unification step has more information to infer the author intent. However, HCL itself doesn't have any builtins for such conversions and so today any messaging about that would need to be generated up at the application layer so the application can refer to whatever functions/etc it provides for type conversion. It isn't clear how to do that with the current design, so we'll leave that to be addressed another day.
- Loading branch information