Commits on Jun 22, 2022

1. go.mod: Upgrade to HCL v2.13.0

   

   apparentlymart committed Jun 22, 2022
   Copy the full SHA

   5335a16 View commit details

   Browse the repository at this point in the history

2. tfdiags: Expose the "extra information" concept from HCL …

   HCL's diagnostic model now includes the idea of "extra information" which
   works by attaching an initially-opaque interface value to each diagnostic
   and then asking callers to type-assert against that value to sniff for
   particular interfaces in order to discover additional machine-readable
   context about a certain diagnostic message.
   
   This commit echoes that idea into our tfdiags API, for now only for
   diagnostics that are backed by an hcl.Diagnostic. All other implementations
   of the diagnostic interface just always return nil, which means they never
   carry any "extra information".
   
   As is typical for our wrapping abstraction, we have here also a modified
   copy of HCL's helper function for conveniently probing a diagnostic for
   information of a particular type, designed to work with our diagnostic
   interface instead of HCL's concrete diagnostic type.

   

   apparentlymart committed Jun 22, 2022
   Copy the full SHA

   783e847 View commit details

   Browse the repository at this point in the history

3. command/format: Include function call information in diagnostics …

   When an error occurs in a function call, the error message text often
   includes references to particular parameters in the function signature.
   
   This commit improves that reporting by also including a summary of the
   full function signature as part of the diagnostic context in that case,
   so a reader can see which parameter is which given that function
   arguments are always assigned positionally and so the parameter names
   do not appear in the caller's source code.

   

   apparentlymart committed Jun 22, 2022
   Copy the full SHA

   cb912de View commit details

   Browse the repository at this point in the history

4. tfdiags: Treat unknown-related or sensitive-related messages differently …

   By observing the sorts of questions people ask in the community, and the
   ways they ask them, we've inferred that various different people have been
   confused by Terraform reporting that a value won't be known until apply
   or that a value is sensitive as part of an error message when that message
   doesn't actually relate to the known-ness and sensitivity of any value.
   
   Quite reasonably, someone who sees Terraform discussing an unfamiliar
   concept like unknown values can assume that it must be somehow relevant to
   the problem being discussed, and so in that sense Terraform's current
   error messages are giving "too much information": information that isn't
   actually helpful in understanding the problem being described, and in the
   worst case is a distraction from understanding the problem being described.
   
   With that in mind then, here we introduce an explicit annotation on
   diagnostic objects that are directly talking about unknown values or
   sensitive values, and then the diagnostic renderer will react to that to
   avoid using the terminology "known only after apply" or "sensitive" in the
   generated diagnostic annotations unless we're rendering a message that is
   explicitly related to one of those topics.
   
   This ends up being a bit of a cross-cutting concern because the code that
   generates these diagnostics and the code that renders them are in separate
   packages and are not directly aware of each other. With that in mind, the
   logic for actually deciding for a particular diagnostic whether it's
   flagged in one of these special ways lives inside the tfdiags package as
   an intermediation point, which both the diagnostic generator (in the core
   package) and the diagnostic renderer can both depend on.

   

   apparentlymart committed Jun 22, 2022
   Copy the full SHA

   afc8726 View commit details

   Browse the repository at this point in the history