This means that printing a Node will produce output that can be used as valid input.
It won't be exactly the same - some spacing may be different - but it will mean the same.
Fixes#4593.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12006047
Phrases like "returns whether or not the image is opaque" could be
describing what the function does (it always returns, regardless of
the opacity) or what it returns (a boolean indicating the opacity).
Even when the "or not" is missing, the phrasing is bizarre.
Go with "reports whether", which is still clunky but at least makes
it clear we're talking about the return value.
These were edited by hand. A few were cleaned up in other ways.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/11699043
For better printing, I recently changed Name to return "<unnamed>" for templates
with empty names, but this causes trouble for the many packages that used "" as
the template name, so restore the old behavior.
It's usually printed as a quoted string anyway, so it should be fine.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/7577044
so that the user don't need to decipher something like this:
template: main:1: expected %!s(parse.itemType=14) in end; got "|"
now they get this:
template: main:1: unexpected "|" in end
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7128054
They now show the correct name, the byte offset on the line, and context for the failed evaluation.
Before:
template: three:7: error calling index: index out of range: 5
After:
template: top:7:20: executing "three" at <index "hi" $>: error calling index: index out of range: 5
Here top is the template that was parsed to create the set, and the error appears with the action
starting at byte 20 of line 7 of "top", inside the template called "three", evaluating the expression
<index "hi" $>.
Also fix a bug in index: it didn't work on strings. Ouch.
Also fix bug in error for index: was showing type of index not slice.
The real previous error was:
template: three:7: error calling index: can't index item of type int
The html/template package's errors can be improved by building on this;
I'll do that in a separate pass.
Extends the API for text/template/parse but only by addition of a field and method. The
old API still works.
Fixes#3188.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6576058
Change the grammar so that field access is a proper operator.
This introduces a new node, ChainNode, into the public (but
actually internal) API of text/template/parse. For
compatibility, we only use the new node type for the specific
construct, which was not parseable before. Therefore this
should be backward-compatible.
Before, .X.Y was a token in the lexer; this CL breaks it out
into .Y applied to .X. But for compatibility we mush them
back together before delivering. One day we might remove
that hack; it's the simple TODO in parse.go/operand.
This change also provides grammatical distinction between
f
and
(f)
which might permit function values later, but not now.
Fixes#3999.
R=golang-dev, dsymonds, gri, rsc, mikesamuel
CC=golang-dev
https://golang.org/cl/6494119
Give the right name for errors, and add a test to check we're
getting the errors we expect.
Also fix an ordering bug (calling add after stopParse) that
caused a nil indirection rather than a helpful error.
Fixes#3280.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/6520043
Other than catching an error case that was missed before, this
CL introduces no changes to the template language or API.
For simplicity, templates use spaces as argument separators.
This means that spaces are significant: .x .y is not the same as .x.y.
In the existing code, these cases are discriminated by the lexer,
but that means for instance that (a b).x cannot be distinguished
from (a b) .x, which is lousy. Although that syntax is not
supported yet, we want to support it and this CL is a necessary
step.
This CL emits a "space" token (actually a run of spaces) from
the lexer so the parser can discriminate these cases. It therefore
fixes a couple of undisclosed bugs ("hi".x is now an error) but
doesn't otherwise change the language. Later CLs will amend
the grammar to make .X a proper operator.
There is one unpleasantness: With space a token, three-token
lookahead is now required when parsing variable declarations
to discriminate them from plain variable references. Otherwise
the change isn't bad.
The CL also moves the debugging print code out of the lexer
into the test, which is the only place it's needed or useful.
Step towards resolving issue 3999.
It still remains to move field chaining out of the lexer
and into the parser and make field access an operator.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6492054
This shouldn't be an error (see issue 3999), but until it's handled
correctly, treat it as one to avoid confusion. Without this CL,
(A).X parses as two arguments.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6473059
Based on work by Russ Cox. From his CL:
This is generally useful but especially helpful when trying
to use the built-in boolean operators. It lets you write:
{{if not (f 1)}} foo {{end}}
{{if and (f 1) (g 2)}} bar {{end}}
{{if or (f 1) (g 2)}} quux {{end}}
instead of
{{if f 1 | not}} foo {{end}}
{{if f 1}}{{if g 2}} bar {{end}}{{end}}
{{$do := 0}}{{if f 1}}{{$do := 1}}{{else if g 2}}{{$do := 1}}{{end}}{{if $do}} quux {{end}}
The result can be a bit LISPy but the benefit in expressiveness and readability
for such a small change justifies it.
I believe no changes are required to html/template.
Fixes#3276.
R=golang-dev, adg, rogpeppe, minux.ma
CC=golang-dev
https://golang.org/cl/6482056
The keyword reprents an untyped nil and is useful for
passing nil values to methods and functions. The
nil will be promoted to the appropriate type when
used; if a type cannot be assigned, an error results.
R=rsc, dsymonds
CC=golang-dev
https://golang.org/cl/6459056
The situation only affects diagnostics but is easy to fix.
When computing lineNumber, use the position of the last item
returned by nextItem rather than the current state of the lexer.
This is internal only and does not affect the API.
Fixes#3886.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/6445061
If the key is not present, return value of the type of the element
not the type of the key. Also fix a test that should have caught this case.
Fixes#3850.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6405078
To avoid goroutines during init, the nextItem function was a
clever workaround. Now that init goroutines are permitted,
restore the original, simpler design.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6282043
Currently, if you pass some data to a template as an interface (e.g. interface{})
and extract that value that value as a parameter for a function, it fails, saying
wrong type.
This is because it is only looking at the interface type, not the interface content.
This CL uses the underlying content as the parameter to the func.
Fixes#3642.
R=golang-dev, r, r
CC=golang-dev
https://golang.org/cl/6218052
Moves the error detection back into execution, where it used to be,
and improves the error message.
Rolls back most of 6009048, which broke lower-case keys in maps.
If it weren't for maps we could detect this at compile time rather than
execution time.
Fixes#3542.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6098051
It's a common error to reference unexported field names in templates,
especially for newcomers. This catches the error at parse time rather than
execute time so the rare few who check errors will notice right away.
These were always an error, so the net behavior is unchanged.
Should break no existing code, just identify the error earlier.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6009048
below do not support '.
This makes package html consistent with package text/template's
HTMLEscape function.
Fixes#3489.
R=rsc, mikesamuel, dsymonds
CC=golang-dev
https://golang.org/cl/5992071
Without this fix, an erroneous template causes a panic; should be caught safely.
The bug did not affect correct templates.
Fixes#3267.
R=golang-dev, dsymonds, rsc
CC=golang-dev
https://golang.org/cl/5900065
1) Poor error checking in variable declarations admitted
$x=2 or even $x%2.
2) Need white space or suitable termination character
after identifiers, so $x+2 doesn't parse, in case we want it
to mean something one day.
Number 2 in particular prevents mistakes that we will have
to honor later and so is necessary for Go 1.
Fixes#3270.
Fixes#3271.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5795073
Missed a case for variadic functions with too few arguments.
The code passes, and with the right error, but might as well record the test case.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5732050
The recent addition of automatic function invocation generated
some troublesome ambiguities. Restore the previous behavior
and compensate by providing a "call" builtin to make it easy to
do what the automatic invocation did, but in a clear and explicit
manner.
Fixes#3140.
At least for now.
R=golang-dev, dsymonds, r
CC=golang-dev
https://golang.org/cl/5720065
Makes it possible for client code to maintain its own profiles,
and also reduces the API surface by giving us a type that
models built-in profiles.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5684056