ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/tfdiags/contextual_test.go

568 lines
12 KiB
Go
Raw Normal View History

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-03-16 00:02:23 +01:00
package tfdiags
import (
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
"fmt"
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-06-29 23:04:56 +02:00
"reflect"
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-03-16 00:02:23 +01:00
"testing"
"github.com/go-test/deep"
"github.com/hashicorp/hcl2/hcl"
"github.com/hashicorp/hcl2/hcl/hclsyntax"
"github.com/zclconf/go-cty/cty"
)
func TestAttributeValue(t *testing.T) {
testConfig := `
foo {
bar = "hi"
}
foo {
bar = "bar"
}
bar {
bar = "woot"
}
baz "a" {
bar = "beep"
}
baz "b" {
bar = "boop"
}
tfdiags: Add more test cases
2018-11-15 15:37:45 +01:00
parent {
nested_str = "hello"
nested_str_tuple = ["aa", "bbb", "cccc"]
nested_num_tuple = [1, 9863, 22]
nested_map = {
first_key = "first_value"
second_key = "2nd value"
}
}
tuple_of_one = ["one"]
tuple_of_two = ["first", "22222"]
root_map = {
first = "1st"
second = "2nd"
}
simple_attr = "val"
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-03-16 00:02:23 +01:00
`
tfdiags: Document missing tests
2018-11-15 15:55:30 +01:00
// TODO: Test ConditionalExpr
// TODO: Test ForExpr
// TODO: Test FunctionCallExpr
// TODO: Test IndexExpr
// TODO: Test interpolation
// TODO: Test SplatExpr
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-03-16 00:02:23 +01:00
f, parseDiags := hclsyntax.ParseConfig([]byte(testConfig), "test.tf", hcl.Pos{Line: 1, Column: 1})
if len(parseDiags) != 0 {
t.Fatal(parseDiags)
}
tfdiags: Add more test cases
2018-11-15 15:37:45 +01:00
emptySrcRng := &SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 33, Column: 1, Byte: 440},
End: SourcePos{Line: 33, Column: 1, Byte: 440},
}
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-03-16 00:02:23 +01:00
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
testCases := []struct {
Diag Diagnostic
ExpectedRange *SourceRange
}{
{
AttributeValue(
Error,
"foo[0].bar",
"detail",
cty.Path{
cty.GetAttrStep{Name: "foo"},
cty.IndexStep{Key: cty.NumberIntVal(0)},
cty.GetAttrStep{Name: "bar"},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 3, Column: 9, Byte: 15},
End: SourcePos{Line: 3, Column: 13, Byte: 19},
},
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-03-16 00:02:23 +01:00
},
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
{
AttributeValue(
Error,
"foo[1].bar",
"detail",
cty.Path{
cty.GetAttrStep{Name: "foo"},
cty.IndexStep{Key: cty.NumberIntVal(1)},
cty.GetAttrStep{Name: "bar"},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 6, Column: 9, Byte: 36},
End: SourcePos{Line: 6, Column: 14, Byte: 41},
},
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-03-16 00:02:23 +01:00
},
tfdiags: Add more test cases
2018-11-15 15:37:45 +01:00
{
AttributeValue(
Error,
"foo[99].bar",
"detail",
cty.Path{
cty.GetAttrStep{Name: "foo"},
cty.IndexStep{Key: cty.NumberIntVal(99)},
cty.GetAttrStep{Name: "bar"},
},
),
emptySrcRng,
},
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
{
AttributeValue(
Error,
"bar.bar",
"detail",
cty.Path{
cty.GetAttrStep{Name: "bar"},
cty.GetAttrStep{Name: "bar"},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 9, Column: 9, Byte: 58},
End: SourcePos{Line: 9, Column: 15, Byte: 64},
},
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-03-16 00:02:23 +01:00
},
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
{
AttributeValue(
Error,
`baz["a"].bar`,
"detail",
cty.Path{
cty.GetAttrStep{Name: "baz"},
cty.IndexStep{Key: cty.StringVal("a")},
cty.GetAttrStep{Name: "bar"},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 12, Column: 9, Byte: 85},
End: SourcePos{Line: 12, Column: 15, Byte: 91},
},
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-03-16 00:02:23 +01:00
},
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
{
AttributeValue(
Error,
`baz["b"].bar`,
"detail",
cty.Path{
cty.GetAttrStep{Name: "baz"},
cty.IndexStep{Key: cty.StringVal("b")},
cty.GetAttrStep{Name: "bar"},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 15, Column: 9, Byte: 112},
End: SourcePos{Line: 15, Column: 15, Byte: 118},
},
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-03-16 00:02:23 +01:00
},
tfdiags: Add more test cases
2018-11-15 15:37:45 +01:00
{
AttributeValue(
Error,
`baz["not_exists"].bar`,
"detail",
cty.Path{
cty.GetAttrStep{Name: "baz"},
cty.IndexStep{Key: cty.StringVal("not_exists")},
cty.GetAttrStep{Name: "bar"},
},
),
emptySrcRng,
},
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
{
// Attribute value with subject already populated should not be disturbed.
// (in a real case, this might've been passed through from a deeper function
// in the call stack, for example.)
&attributeDiagnostic{
tfdiags: Add more test cases
2018-11-15 15:37:45 +01:00
attrPath: cty.Path{cty.GetAttrStep{Name: "foo"}},
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
diagnosticBase: diagnosticBase{
summary: "preexisting",
detail: "detail",
},
subject: &SourceRange{
Filename: "somewhere_else.tf",
},
},
&SourceRange{
Filename: "somewhere_else.tf",
},
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-03-16 00:02:23 +01:00
},
tfdiags: Add more test cases
2018-11-15 15:37:45 +01:00
{
// Missing path
&attributeDiagnostic{
diagnosticBase: diagnosticBase{
summary: "missing path",
},
},
nil,
},
// Nested attributes
{
AttributeValue(
Error,
"parent.nested_str",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_str"},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 18, Column: 16, Byte: 145},
End: SourcePos{Line: 18, Column: 23, Byte: 152},
},
},
{
AttributeValue(
Error,
"parent.nested_str_tuple[99]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_str_tuple"},
cty.IndexStep{Key: cty.NumberIntVal(99)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 19, Column: 3, Byte: 155},
End: SourcePos{Line: 19, Column: 19, Byte: 171},
},
},
{
AttributeValue(
Error,
"parent.nested_str_tuple[0]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_str_tuple"},
cty.IndexStep{Key: cty.NumberIntVal(0)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 19, Column: 23, Byte: 175},
End: SourcePos{Line: 19, Column: 27, Byte: 179},
},
},
{
AttributeValue(
Error,
"parent.nested_str_tuple[2]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_str_tuple"},
cty.IndexStep{Key: cty.NumberIntVal(2)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 19, Column: 36, Byte: 188},
End: SourcePos{Line: 19, Column: 42, Byte: 194},
},
},
{
AttributeValue(
Error,
"parent.nested_num_tuple[0]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_num_tuple"},
cty.IndexStep{Key: cty.NumberIntVal(0)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 20, Column: 23, Byte: 218},
End: SourcePos{Line: 20, Column: 24, Byte: 219},
},
},
{
AttributeValue(
Error,
"parent.nested_num_tuple[1]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_num_tuple"},
cty.IndexStep{Key: cty.NumberIntVal(1)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 20, Column: 26, Byte: 221},
End: SourcePos{Line: 20, Column: 30, Byte: 225},
},
},
{
AttributeValue(
Error,
"parent.nested_map.first_key",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_map"},
cty.IndexStep{Key: cty.StringVal("first_key")},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 22, Column: 19, Byte: 266},
End: SourcePos{Line: 22, Column: 30, Byte: 277},
},
},
{
AttributeValue(
Error,
"parent.nested_map.second_key",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_map"},
cty.IndexStep{Key: cty.StringVal("second_key")},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 23, Column: 19, Byte: 297},
End: SourcePos{Line: 23, Column: 28, Byte: 306},
},
},
{
AttributeValue(
Error,
"parent.nested_map.undefined_key",
"detail",
cty.Path{
cty.GetAttrStep{Name: "parent"},
cty.GetAttrStep{Name: "nested_map"},
cty.IndexStep{Key: cty.StringVal("undefined_key")},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 21, Column: 3, Byte: 233},
End: SourcePos{Line: 21, Column: 13, Byte: 243},
},
},
// Root attributes of complex types
{
AttributeValue(
Error,
"tuple_of_one[0]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "tuple_of_one"},
cty.IndexStep{Key: cty.NumberIntVal(0)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 26, Column: 17, Byte: 330},
End: SourcePos{Line: 26, Column: 22, Byte: 335},
},
},
{
AttributeValue(
Error,
"tuple_of_two[0]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "tuple_of_two"},
cty.IndexStep{Key: cty.NumberIntVal(0)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 27, Column: 17, Byte: 353},
End: SourcePos{Line: 27, Column: 24, Byte: 360},
},
},
{
AttributeValue(
Error,
"tuple_of_two[1]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "tuple_of_two"},
cty.IndexStep{Key: cty.NumberIntVal(1)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 27, Column: 26, Byte: 362},
End: SourcePos{Line: 27, Column: 33, Byte: 369},
},
},
{
AttributeValue(
Error,
"tuple_of_one[null]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "tuple_of_one"},
cty.IndexStep{Key: cty.NullVal(cty.Number)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 26, Column: 1, Byte: 314},
End: SourcePos{Line: 26, Column: 13, Byte: 326},
},
},
{
// index out of range
AttributeValue(
Error,
"tuple_of_two[99]",
"detail",
cty.Path{
cty.GetAttrStep{Name: "tuple_of_two"},
cty.IndexStep{Key: cty.NumberIntVal(99)},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 27, Column: 1, Byte: 337},
End: SourcePos{Line: 27, Column: 13, Byte: 349},
},
},
{
AttributeValue(
Error,
"root_map.first",
"detail",
cty.Path{
cty.GetAttrStep{Name: "root_map"},
cty.IndexStep{Key: cty.StringVal("first")},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 29, Column: 13, Byte: 396},
End: SourcePos{Line: 29, Column: 16, Byte: 399},
},
},
{
AttributeValue(
Error,
"root_map.second",
"detail",
cty.Path{
cty.GetAttrStep{Name: "root_map"},
cty.IndexStep{Key: cty.StringVal("second")},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 30, Column: 13, Byte: 413},
End: SourcePos{Line: 30, Column: 16, Byte: 416},
},
},
{
AttributeValue(
Error,
"root_map.undefined_key",
"detail",
cty.Path{
cty.GetAttrStep{Name: "root_map"},
cty.IndexStep{Key: cty.StringVal("undefined_key")},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 28, Column: 1, Byte: 371},
End: SourcePos{Line: 28, Column: 9, Byte: 379},
},
},
{
AttributeValue(
Error,
"simple_attr",
"detail",
cty.Path{
cty.GetAttrStep{Name: "simple_attr"},
},
),
&SourceRange{
Filename: "test.tf",
Start: SourcePos{Line: 32, Column: 15, Byte: 434},
End: SourcePos{Line: 32, Column: 20, Byte: 439},
},
},
{
// This should never happen as error should always point to an attribute
// or index of an attribute, but we should not crash if it does
AttributeValue(
Error,
"key",
"index_step",
cty.Path{
cty.IndexStep{Key: cty.StringVal("key")},
},
),
emptySrcRng,
},
{
// This should never happen as error should always point to an attribute
// or index of an attribute, but we should not crash if it does
AttributeValue(
Error,
"key.another",
"index_step",
cty.Path{
cty.IndexStep{Key: cty.StringVal("key")},
cty.IndexStep{Key: cty.StringVal("another")},
},
),
emptySrcRng,
},
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-03-16 00:02:23 +01:00
}
tfdiags: Restructure tests into subtests
2018-11-14 12:45:04 +01:00
for i, tc := range testCases {
t.Run(fmt.Sprintf("%d:%s", i, tc.Diag.Description()), func(t *testing.T) {
var diags Diagnostics
diags = diags.Append(tc.Diag)
gotDiags := diags.InConfigBody(f.Body)
gotRange := gotDiags[0].Source().Subject
for _, problem := range deep.Equal(gotRange, tc.ExpectedRange) {
t.Error(problem)
}
})
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-03-16 00:02:23 +01:00
}
}
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-06-29 23:04:56 +02:00
func TestGetAttribute(t *testing.T) {
path := cty.Path{
cty.GetAttrStep{Name: "foo"},
cty.IndexStep{Key: cty.NumberIntVal(0)},
cty.GetAttrStep{Name: "bar"},
}
d := AttributeValue(
Error,
"foo[0].bar",
"detail",
path,
)
p := GetAttribute(d)
if !reflect.DeepEqual(path, p) {
t.Fatalf("paths don't match:\nexpected: %#v\ngot: %#v", path, p)
}
}