Commit Graph

7 Commits

Author SHA1 Message Date
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.
2019-10-02 15:10:21 -07:00
Kristin Laemmert f8a5e17d3d
command/format: improve "source" of error messages regarding missing arguments (#20907)
* vendor: update hcl2 dependency
* command/format: revert diagnostic format behavior if snippet or highlight range is empty
2019-04-03 14:04:59 -04:00
Radek Simko aca52ce2b9
tfdiags: Document missing tests 2018-11-15 14:57:42 +00:00
Radek Simko 9e0c6ab5e0
tfdiags: Add more test cases 2018-11-15 14:57:42 +00:00
Radek Simko 547006d943
tfdiags: Restructure tests into subtests 2018-11-15 14:57:42 +00:00
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.
2018-10-16 18:50:29 -07:00
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.
2018-10-16 18:24:10 -07:00