update zclsyntax to hclsyntax in various comments and strings

These are remnants of the project HCL was forked from.
This commit is contained in:
Fatih Arslan 2018-01-24 08:54:38 +03:00 committed by Martin Atkins
parent 613331e829
commit f87600a7d9
9 changed files with 19 additions and 19 deletions

View File

@ -1113,7 +1113,7 @@ func TestStaticExpressionList(t *testing.T) {
}
first, ok := exprs[0].(*LiteralValueExpr)
if !ok {
t.Fatalf("first expr has wrong type %T; want *zclsyntax.LiteralValueExpr", exprs[0])
t.Fatalf("first expr has wrong type %T; want *hclsyntax.LiteralValueExpr", exprs[0])
}
if !first.Val.RawEquals(cty.Zero) {
t.Fatalf("wrong first value %#v; want cty.Zero", first.Val)

View File

@ -24,7 +24,7 @@ func main() {
fmt.Fprintf(os.Stderr, "error while parsing: %s\n", err)
os.Exit(1)
}
pkg := pkgs["zclsyntax"]
pkg := pkgs["hclsyntax"]
// Walk all the files and collect the receivers of any "Value" methods
// that look like they are trying to implement Expression.
@ -83,7 +83,7 @@ func main() {
}
const outputPreamble = `package zclsyntax
const outputPreamble = `package hclsyntax
// Generated by expression_vars_get.go. DO NOT EDIT.
// Run 'go generate' on this package to update the set of functions here.

View File

@ -9,8 +9,8 @@ import (
// diagnostics returns true, the returned body is likely to be incomplete
// and should therefore be used with care.
//
// The body in the returned file has dynamic type *zclsyntax.Body, so callers
// may freely type-assert this to get access to the full zclsyntax API in
// The body in the returned file has dynamic type *hclsyntax.Body, so callers
// may freely type-assert this to get access to the full hclsyntax API in
// situations where detailed access is required. However, most common use-cases
// should be served using the hcl.Body interface to ensure compatibility with
// other configurationg syntaxes, such as JSON.

View File

@ -1,4 +1,4 @@
package zclsyntax
package hclsyntax
import (
"bytes"

View File

@ -3,7 +3,7 @@
This is the specification for the JSON serialization for hcl. HCL is a system
for defining configuration languages for applications. The HCL information
model is designed to support multiple concrete syntaxes for configuration,
and this JSON-based format complements [the native syntax](../zclsyntax/spec.md)
and this JSON-based format complements [the native syntax](../hclsyntax/spec.md)
by being easy to machine-generate, whereas the native syntax is oriented
towards human authoring and maintenence.

View File

@ -279,7 +279,7 @@ func (e *expression) Value(ctx *hcl.EvalContext) (cty.Value, hcl.Diagnostics) {
v.SrcRange.Filename,
// This won't produce _exactly_ the right result, since
// the zclsyntax parser can't "see" any escapes we removed
// the hclsyntax parser can't "see" any escapes we removed
// while parsing JSON, but it's better than nothing.
hcl.Pos{
Line: v.SrcRange.Start.Line,
@ -336,7 +336,7 @@ func (e *expression) Variables() []hcl.Traversal {
v.SrcRange.Filename,
// This won't produce _exactly_ the right result, since
// the zclsyntax parser can't "see" any escapes we removed
// the hclsyntax parser can't "see" any escapes we removed
// while parsing JSON, but it's better than nothing.
hcl.Pos{
Line: v.SrcRange.Start.Line,

View File

@ -7,7 +7,7 @@ concrete syntaxes for configuration, each with a mapping to the model defined
in this specification.
The two primary syntaxes intended for use in conjunction with this model are
[the HCL native syntax](./zclsyntax/spec.md) and [the JSON syntax](./json/spec.md).
[the HCL native syntax](./hclsyntax/spec.md) and [the JSON syntax](./json/spec.md).
In principle other syntaxes are possible as long as either their language model
is sufficiently rich to express the concepts described in this specification
or the language targets a well-defined subset of the specification.
@ -159,7 +159,7 @@ a computation in terms of literal values, variables, and functions.
Each syntax defines its own representation of expressions. For syntaxes based
in languages that do not have any non-literal expression syntax, it is
recommended to embed the template language from
[the native syntax](./zclsyntax/spec.md) e.g. as a post-processing step on
[the native syntax](./hclsyntax/spec.md) e.g. as a post-processing step on
string literals.
### Expression Evaluation

View File

@ -3,18 +3,18 @@ package hclwrite
import (
"sort"
"github.com/hashicorp/hcl2/hcl/hclsyntax"
"github.com/hashicorp/hcl2/hcl"
"github.com/hashicorp/hcl2/hcl/hclsyntax"
)
// Our "parser" here is actually not doing any parsing of its own. Instead,
// it leans on the native parser in zclsyntax, and then uses the source ranges
// it leans on the native parser in hclsyntax, and then uses the source ranges
// from the AST to partition the raw token sequence to match the raw tokens
// up to AST nodes.
//
// This strategy feels somewhat counter-intuitive, since most of the work the
// parser does is thrown away here, but this strategy is chosen because the
// normal parsing work done by zclsyntax is considered to be the "main case",
// normal parsing work done by hclsyntax is considered to be the "main case",
// while modifying and re-printing source is more of an edge case, used only
// in ancillary tools, and so it's good to keep all the main parsing logic
// with the main case but keep all of the extra complexity of token wrangling
@ -30,7 +30,7 @@ func parse(src []byte, filename string, start hcl.Pos) (*File, hcl.Diagnostics)
return nil, diags
}
// To do our work here, we use the "native" tokens (those from zclsyntax)
// To do our work here, we use the "native" tokens (those from hclsyntax)
// to match against source ranges in the AST, but ultimately produce
// slices from our sequence of "writer" tokens, which contain only
// *relative* position information that is more appropriate for
@ -333,7 +333,7 @@ func parseExpression(nativeExpr hclsyntax.Expression, from inputTokens) *Express
}
}
// writerTokens takes a sequence of tokens as produced by the main zclsyntax
// writerTokens takes a sequence of tokens as produced by the main hclsyntax
// package and transforms it into an equivalent sequence of tokens using
// this package's own token model.
//
@ -389,7 +389,7 @@ func writerTokens(nativeTokens hclsyntax.Tokens) Tokens {
// true then it will make a best effort that may produce strange results at
// the boundaries.
//
// Native zclsyntax tokens are used here, because they contain the necessary
// Native hclsyntax tokens are used here, because they contain the necessary
// absolute position information. However, since writerTokens produces a
// correlatable sequence of writer tokens, the resulting indices can be
// used also to index into its result, allowing the partitioning of writer
@ -488,7 +488,7 @@ func partitionLineEndTokens(toks hclsyntax.Tokens) (afterComment, afterNewline i
return len(toks), len(toks)
}
// lexConfig uses the zclsyntax scanner to get a token stream and then
// lexConfig uses the hclsyntax scanner to get a token stream and then
// rewrites it into this package's token model.
//
// Any errors produced during scanning are ignored, so the results of this

View File

@ -22,7 +22,7 @@ type TokenGen interface {
type TokenCallback func(*Token)
// Token is a single sequence of bytes annotated with a type. It is similar
// in purpose to zclsyntax.Token, but discards the source position information
// in purpose to hclsyntax.Token, but discards the source position information
// since that is not useful in code generation.
type Token struct {
Type hclsyntax.TokenType