-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent ObjectWithOptionalAttrs
from escaping
#29559
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a fine compromise to keep things roughly rational until we're next working on the optional attributes experiment. Thanks for digging through all this!
Objects with optional attributes are only used for the decoding of HCL, and those types should never be exposed elsewhere within terraform. Separate the external ImpliedType method from the cty.Type generated internally for the decoder spec. This unfortunately causes our ImpliedType method to return a different type than the hcldec.ImpliedType function, but the former is only used within terraform for concrete values, while the latter is used to decode HCL. Renaming the ImpliedType methods could be done to further differentiate them, but that does cause fairly large diff in the codebase that does not seem worth the effort at this time.
In order to handle optional attributes, the Variable type needs to keep track of the type constraint for decoding and conversion, as well as the concrete type for creating values and type comparison. Since the Type field is referenced throughout the codebase, and for future refactoring if the handling of optional attributes changes significantly, the constraint is now loaded into an entirely new field called ConstraintType. This prevents types containing ObjectWithOptionalAttrs from escaping the decode/conversion codepaths into the rest of the codebase.
d7272b7
to
7f26531
Compare
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
The use of the
ObjectWithOptionalAttrs
type should not escape into the type general population. It is only used for the decoding of configuration, and conversions between object values, and otherwise should never be seen in any value or type that could be used to instantiate a value.Separate the external
ImpliedType
methods from thecty.Type
generated internally for the decoder spec in configschema. Along with preventing optional attrs from escaping viaImpliedType
, this separation allows the decoding codepaths to continue running without the overhead ofWithoutOptionalAttributesDeep
, which is verified by the benchmarks for extremely large schemasThis unfortunately does cause our
ImpliedType
method to possibly return a different type than thehcldec.ImpliedType
function, but the former is only used within terraform for concrete values, while the latter is used to decode HCL. Renaming theImpliedType
methods internally could be done to further differentiate them, but that does cause fairly large diff in the codebase that does not seem worth the effort at this time.In order to handle optional attributes for the
module_variable_optional_attrs
experiment, theconfigs.Variable
type needs to keep track of the type constraint for decoding and conversion, as well as the concrete type for creating values and type comparison. Since theType
field is referenced throughout the codebase, and for future refactoring if the handling of optional attributes changes significantly, the type constraint is now loaded into an entirely new field calledConstraintType
. This prevents types containingObjectWithOptionalAttrs
from escaping the decode/conversion codepaths into the rest of the codebase.Fixes #29538