github.com/hashicorp/hcl/v2@v2.20.0/gohcl/doc.go (about)

     1  // Copyright (c) HashiCorp, Inc.
     2  // SPDX-License-Identifier: MPL-2.0
     3  
     4  // Package gohcl allows decoding HCL configurations into Go data structures.
     5  //
     6  // It provides a convenient and concise way of describing the schema for
     7  // configuration and then accessing the resulting data via native Go
     8  // types.
     9  //
    10  // A struct field tag scheme is used, similar to other decoding and
    11  // unmarshalling libraries. The tags are formatted as in the following example:
    12  //
    13  //    ThingType string `hcl:"thing_type,attr"`
    14  //
    15  // Within each tag there are two comma-separated tokens. The first is the
    16  // name of the corresponding construct in configuration, while the second
    17  // is a keyword giving the kind of construct expected. The following
    18  // kind keywords are supported:
    19  //
    20  //    attr (the default) indicates that the value is to be populated from an attribute
    21  //    block indicates that the value is to populated from a block
    22  //    label indicates that the value is to populated from a block label
    23  //    optional is the same as attr, but the field is optional
    24  //    remain indicates that the value is to be populated from the remaining body after populating other fields
    25  //
    26  // "attr" fields may either be of type *hcl.Expression, in which case the raw
    27  // expression is assigned, or of any type accepted by gocty, in which case
    28  // gocty will be used to assign the value to a native Go type.
    29  //
    30  // "block" fields may be a struct that recursively uses the same tags, or a
    31  // slice of such structs, in which case multiple blocks of the corresponding
    32  // type are decoded into the slice.
    33  //
    34  // "body" can be placed on a single field of type hcl.Body to capture
    35  // the full hcl.Body that was decoded for a block. This does not allow leftover
    36  // values like "remain", so a decoding error will still be returned if leftover
    37  // fields are given. If you want to capture the decoding body PLUS leftover
    38  // fields, you must specify a "remain" field as well to prevent errors. The
    39  // body field and the remain field will both contain the leftover fields.
    40  //
    41  // "label" fields are considered only in a struct used as the type of a field
    42  // marked as "block", and are used sequentially to capture the labels of
    43  // the blocks being decoded. In this case, the name token is used only as
    44  // an identifier for the label in diagnostic messages.
    45  //
    46  // "optional" fields behave like "attr" fields, but they are optional
    47  // and will not give parsing errors if they are missing.
    48  //
    49  // "remain" can be placed on a single field that may be either of type
    50  // hcl.Body or hcl.Attributes, in which case any remaining body content is
    51  // placed into this field for delayed processing. If no "remain" field is
    52  // present then any attributes or blocks not matched by another valid tag
    53  // will cause an error diagnostic.
    54  //
    55  // Only a subset of this tagging/typing vocabulary is supported for the
    56  // "Encode" family of functions. See the EncodeIntoBody docs for full details
    57  // on the constraints there.
    58  //
    59  // Broadly-speaking this package deals with two types of error. The first is
    60  // errors in the configuration itself, which are returned as diagnostics
    61  // written with the configuration author as the target audience. The second
    62  // is bugs in the calling program, such as invalid struct tags, which are
    63  // surfaced via panics since there can be no useful runtime handling of such
    64  // errors and they should certainly not be returned to the user as diagnostics.
    65  package gohcl