7 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494)

Author	SHA1	Message	Date
James Bardin	6caa5d23e2	fix diagnostics handling ... Located all non-test paths where a Diagnostic type was assigned to an error variable.	7 years ago
Martin Atkins	39e609d5fd	vendor: switch to HCL 2.0 in the HCL repository ... Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.	7 years ago
Radek Simko	ec127e4a7b	tfdiags: Detect more complex cfgs in ElaborateFromConfigBody	8 years ago
Sander van Harmelen	48ef7ecfa6	Updates after running `make fmt` with Go v1.11.1	8 years ago
Martin Atkins	e25f79ed28	plugin/convert: Show approximate location context for all provider errors ... Even if a provider doesn't indicate a specific attribute as the cause of a resource operation error, we know the error relates to some aspect of the resource, so we'll include that approximate information in the result so that we don't produce user-hostile error messages with no context whatsoever. Later we can hopefully refine this to place the source range on the header of the configuration block rather than on an empty part of the body, but that'll require some more complex rework here and so for now we'll just accept this as an interim state so that the user can at least figure out which resource block the error is coming from.	8 years ago
James Bardin	83538bbecb	add tfdiags.GetAttribute ... The only contextual information returned by the plugins in a diagnostic is an attribute path. In order to test the conversions, we need to be able to extract the cty.Path from a diagnostic if it exists.	8 years ago
Martin Atkins	e309675853	tfdiags: Contextual diagnostics ... The usual usage of diagnostics requires us to pass around source location information to everywhere that might generate a diagnostic, and that is always the best way to get the most precise diagnostic source locations. However, it's impractical to require source location information to be retained in every Terraform subsystem, and so this new idea of "contextual diagnostics" allows us to separate the generation of a diagnostic from the resolution of its source location, instead resolving the location information as a post-processing step once the call stack unwinds to a place where there is enough context to find it. This is necessarily a less precise approach than reading the source ranges directly from the configuration AST, but gives us an alternative to no diagnostics at all in portions of Terraform where full location information is not available. This is a best-effort sort of thing which will get as precise as it can but may return a range in a parent block if the precise location of a particular attribute cannot be found. Diagnostics that rely on this mechanism should include some other contextual information in the detail message to make up for any loss of precision that results.	8 years ago