11 Commits (f8fb61de12dea9ac94de3060a0d3e97ce9b5480b)

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	4 months ago
Daniel Schmidt	75445e1ef8	use a string as deprecation origin to help with indirect references ... We want to be able to give better information if e.g. the entire module is stored in a local and the deprecated value is only later used. Where the diag is emitted we might only see the local and not the true origin of the deprecation A string identifying the source of the deprecation should help	5 months ago
Daniel Schmidt	a96df66a9a	display origin of deprecated value in diagnostic	5 months ago
Radek Simko	4e00e1ecdb	fix: Avoid crash on test failure in BinaryOpExpr in function call (#37071) ... * fix: Avoid crash on test failure in BinaryOpExpr in function call * add changelog entry	1 year ago
Samsondeen	1bd312f155	Produce detailed diagnostic objects when test run assertions fail (#36522)	1 year ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Martin Atkins	90ea7b0bc5	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.	4 years ago
Martin Atkins	31aee9650e	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.	4 years ago
James Bardin	d9dfd451ea	update to use typed sensitive marks	5 years ago
Martin Atkins	ffe056bacb	Move command/ to internal/command/ ... This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago