| Age | Commit message (Collapse) | Author |
|---|
|
Template.New calls t.init, which allocates several items that
are immediately rewritten by copy, so avoid the call to New
Change-Id: I16c7cb001bbcd14cf547c1a2db2734a2f8214e7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/182757
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
|
|
After Go.1.10+ strings.Builder is known as more efficient in
concatenating and building strings than bytes.Buffer.
In this CL,
there is a minor logic fix for getting advantage of strings.builder.
name old time/op new time/op delta
DefinedTemplate-8 543ns ± 3% 512ns ± 2% -5.73% (p=0.000 n=8+8)
name old alloc/op new alloc/op delta
DefinedTemplate-8 192B ± 0% 160B ± 0% -16.67% (p=0.000 n=8+8)
name old allocs/op new allocs/op delta
DefinedTemplate-8 5.00 ± 0% 5.00 ± 0% ~ (all equal)
Change-Id: Icda0054d146e6c5e32ed8a4d13221bb6850d31b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/175261
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The scanner was changed to accept the new Go number literal syntax
of which separators are a part. Making them opt-in is inconsistent
with the rest of the changes. For comparison, the strconv package
also accepts the new number literals including separators with the
various conversion routines, if no explicit number base is given.
Updates #28493.
Change-Id: Ifaae2225a9565364610813658bfe692901dd3ccd
Reviewed-on: https://go-review.googlesource.com/c/go/+/184080
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Fixes #32661.
Change-Id: I32dc4e7b276b95ac2e87a384caa6c48702368d05
Reviewed-on: https://go-review.googlesource.com/c/go/+/183077
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
This change updates the doc comments of the various ParseGlob functions
and methods to state that they use the semantics of filepath.Match when
matching the file name pattern.
Fixes #30608
Change-Id: Iee4bdc0a2a2f8647d1f9a910e4d72a5de9204d11
Reviewed-on: https://go-review.googlesource.com/c/go/+/179739
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
In particular, the returned template isn't independent from the parent.
For example, it can't be parsed concurrently with other children
templates. Only methods which are explicitly safe for concurrent use,
like Execute, may be used concurrently.
Fixes #30281.
Change-Id: Idc84bf4199c035316cdb83b950fd4a8f2a71cd0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/172297
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
The new slice function returns the result of slicing its first argument by
the following arguments. Thus {{slice x 1 3}} is, in Go syntax, x[1:3].
Each sliced item must be a string, slice, or array.
Closed #30153
RELNOTE=yes
Change-Id: I63188c422848cee3d383a64dc4d046e3a1767c63
Reviewed-on: https://go-review.googlesource.com/c/go/+/161762
Reviewed-by: Rob Pike <r@golang.org>
|
|
Shorten some of the longest tests that run during all.bash.
Removes 7r 50u 21s from all.bash.
After this change, all.bash is under 5 minutes again on my laptop.
For #26473.
Change-Id: Ie0460aa935808d65460408feaed210fbaa1d5d79
Reviewed-on: https://go-review.googlesource.com/c/go/+/177559
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Before this commit, the two logically equivalent conditionals below would
produce different output:
{{ if not .NonEmptyInterfaceTypedNil }}OK{{ else }}{{ end }}
{{ if .NonEmptyInterfaceTypedNil }}{{ else }}OK{{ end }}
The functions `not`, `or`, and `and` all use the same `truth` function, which
unwraps any concrete interface value before passing it to `isTrue`.
`if` and `with` also use `isTrue` to establish truth, but was missing the
interface indirect call.
Fixes #30501
Change-Id: I9c49eed41e737d8f162e39bef1c3b82fd5518fed
GitHub-Last-Rev: 95fc2c82f26d24a457de4deaa7e5756718fbf07c
GitHub-Pull-Request: golang/go#30534
Reviewed-on: https://go-review.googlesource.com/c/go/+/164958
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
|
|
Add Unwrap methods to types which wrap an underlying error:
"encodinc/csv".ParseError
"encoding/json".MarshalerError
"net/http".transportReadFromServerError
"net".OpError
"net".DNSConfigError
"net/url".Error
"os/exec".Error
"signal/internal/pty".PtyError
"text/template".ExecError
Add os.ErrTemporary. A case could be made for putting this error
value in package net, since no exported error types in package os
include a Temporary method. However, syscall errors returned from
the os package do include this method.
Add Is methods to error types with a Timeout or Temporary method,
making errors.Is(err, os.Err{Timeout,Temporary}) equivalent to
testing the corresponding method:
"context".DeadlineExceeded
"internal/poll".TimeoutError
"net".adrinfoErrno
"net".OpError
"net".DNSError
"net/http".httpError
"net/http".tlsHandshakeTimeoutError
"net/pipe".timeoutError
"net/url".Error
Updates #30322
Updates #29934
Change-Id: I409fb20c072ea39116ebfb8c7534d493483870dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/170037
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
|
|
I recently modified tabwriter to reduce the number of defers due to
flush calls. However, I forgot to notice that the new function
flushNoDefers can no longer return an error, due to the lack of the
defer.
In crypto/tls, hashForServerKeyExchange never returned a non-nil error,
so simplify the code.
Finally, in go/types and net we can find a few trivially unused
parameters, so remove them.
Change-Id: I54c8de83fbc944df432453b55c93008d7e810e61
Reviewed-on: https://go-review.googlesource.com/c/go/+/174131
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
|
|
lexSpace consumed all spaces, even if the last one was part of a right
delimiter like " -}}". Thus, "3 -}}" wouldn't lex as "3" and a right
delimiter, but as "3", "-", and "}}".
To fix that, make lexSpace stop if it encounters a right delimiter.
Fixes #30948.
Change-Id: I80a5546e5809e54f6823e2bf3a57a7e8808329be
Reviewed-on: https://go-review.googlesource.com/c/go/+/168457
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
|
|
Lines with single cells prompt a flush. Unfortunately, a call to
Writer.Flush also means two defers, which is an expensive operation to
do if many lines consist of single cells.
This is common when formatting code with aligned comments. Most lines
aren't going to have any comments at all, so the performance hit is
going to be noticeable.
The Write method already has a "defer handlePanic" of its own, so we
don't need to worry about panics leaking out. The error will now mention
"Write" instead of "Flush" if a panic is encountered during that nested
flush, but arguably that's a good thing; the user called Write, not
Flush.
For the reset call, add a non-deferred call as part of flushNoDefers, as
that's still necessary. Otherwise, the exported Flush method still does
a "defer b.reset".
The current tabwriter benchmarks are unaffected, since they don't
contain many single-cell lines, and because lines are written one at a
time. For that reason, we add a benchmark which has both of these
characteristics.
name old time/op new time/op delta
Code-8 2.72µs ± 0% 1.77µs ± 0% -34.88% (p=0.000 n=6+5)
name old alloc/op new alloc/op delta
Code-8 648B ± 0% 648B ± 0% ~ (all equal)
name old allocs/op new allocs/op delta
Code-8 13.0 ± 0% 13.0 ± 0% ~ (all equal)
Perhaps unsurprisingly, go/printer also gets a bit faster, as it too
buffers its output before writing it to tabwriter.
name old time/op new time/op delta
Print-8 6.53ms ± 0% 6.39ms ± 0% -2.22% (p=0.008 n=5+5)
Change-Id: Ie01fea5ced43886a9eb796cb1e6c810f7a810853
Reviewed-on: https://go-review.googlesource.com/c/go/+/166797
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
If a for loop has a simple condition and begins with a simple
"if x { break; }"; we can simply add "!x" to the loop's condition.
While at it, simplify a few assignments to use the common pattern
"x := staticDefault; if cond { x = otherValue(); }".
Finally, simplify a couple of var declarations.
Change-Id: I413982c6abd32905adc85a9a666cb3819139c19f
Reviewed-on: https://go-review.googlesource.com/c/go/+/165342
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Trying to call a method on a nil interface is a panic in Go. For
example:
var stringer fmt.Stringer
println(stringer.String()) // nil pointer dereference
In https://golang.org/cl/143097 we started recovering panics encountered
during function and method calls. However, we didn't handle this case,
as text/template panics before evalCall is ever run.
In particular, reflect's MethodByName will panic if the receiver is of
interface kind and nil:
panic: reflect: Method on nil interface value
Simply add a check for that edge case, and have Template.Execute return
a helpful error. Note that Execute shouldn't just error if the interface
contains a typed nil, since we're able to find a method to call in that
case.
Finally, add regression tests for both the nil and typed nil interface
cases.
Fixes #30143.
Change-Id: Iffb21b40e14ba5fea0fcdd179cd80d1f23cabbab
Reviewed-on: https://go-review.googlesource.com/c/161761
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
If we're accessing a field on a nil struct pointer, and that field is
present in the type, we should print a "nil pointer evaluating X.Y" error
instead of the broader "can't evaluate field Y in X". The latter error
should still be used for the cases where the field is simply missing.
While at it, remove the isNil checks in the struct and map cases. The
indirect func will only return a true isNil when returning a pointer or
interface reflect.Value, so it's impossible for either of these checks
to be useful.
Finally, extend the test suite to test a handful of these edge cases,
including the one shown in the original issue.
Fixes #29137.
Change-Id: I53408ced8a7b53807a0a8461b6baef1cd01d25ae
Reviewed-on: https://go-review.googlesource.com/c/153341
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
This CL updates text/template's scanner to accept the
new number syntaxes:
- Hexadecimal floating-point values.
- Digit-separating underscores.
- Leading 0b and 0o prefixes.
See golang.org/design/19308-number-literals for background.
For #12711.
For #19308.
For #28493.
For #29008.
Change-Id: I68c16ea35c3f506701063781388de72bafee6b8d
Reviewed-on: https://go-review.googlesource.com/c/160248
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This is a follow-up on https://golang.org/cl/161199 which introduced
the new Go 2 number literals to text/scanner.
That change introduced a bug by allowing decimal and hexadecimal floats
to be consumed even if the scanner was not configured to accept floats.
This CL changes the code to not consume a radix dot '.' or exponent
unless the scanner is configured to accept floats.
This CL also introduces a new mode "AllowNumberbars" which controls
whether underbars '_' are permitted as digit separators in numbers
or not.
There is a possibility that we may need to refine text/scanner
further (e.g., the Float mode now includes hexadecimal floats
which it didn't recognize before). We're very early in the cycle,
so let's see how it goes.
RELNOTE=yes
Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.
Fixes #30320.
Change-Id: I6481d314f0384e09ef6803ffad38dc529b1e89a3
Reviewed-on: https://go-review.googlesource.com/c/163079
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This CL introduces text/scanner support for the new binary and octal integer
literals, hexadecimal floats, and digit separators for all number literals.
The new code is closely mirroring the respective code for number literals in
cmd/compile/internal/syntax/scanner.go.
Uniformly use the term "invalid" rather than "illegal" in error messages
to match the respective error messages in the other scanners directly.
R=Go1.13
Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.
Change-Id: I2f291de13ba5afc0e530cd8326e6bf4c3858ebac
Reviewed-on: https://go-review.googlesource.com/c/161199
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Make sure Scanner.tokEnd is set before we call Scanner.Error
and update documentation accordingly.
(Until now tokEnd was only set before returning from Scan,
so a call to TokenText during error handling may have crashed.)
While at it, tighten a check in Scanner.TokenText to ensure
Scanner.tokEnd >= Scanner.tokPos if we have a token.
Also, silence error messages to Stderr in unrelated TestIllegalExponent.
Fixes #29723.
Change-Id: Ia97beeae91eaf9e0ed3dada0a806f1f7122461cc
Reviewed-on: https://go-review.googlesource.com/c/157819
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
|
|
The pipeline parsing code was unnecessarily complex. It used a for loop
with a trailing break, a complex switch, and up to seven levels of
indentation.
Instead, drop the loop in favor of a single named goto with a comment,
and flatten out the complex switch to be easier to follow. Two lines of
code are now duplicated, but they're simple and only three lines apart.
While at it, move the pipe initialization further up to remove the need
for three variables.
Change-Id: I07b29de195f4000336219aadeadeacaaa4285c58
Reviewed-on: https://go-review.googlesource.com/c/145285
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
The package used to accept invalid range pipelines, such as:
{{range $k, .}}
{{range $k, 123 := .}}
This is because the logic that allowed a range pipeline to declare
multiple variables was broken. When encountering a single comma inside a
range pipeline, it would happily continue parsing a second variable,
even if we didn't have a variable token at all.
Then, the loop would immediately break, and we'd parse the pipeline we'd
be ranging over. That is, we'd parse {{range $k, .}} as if it were
{{range $k = .}}.
To fix this, only allow the loop to continue if we know we're going to
parse another variable or a token that would end the pipeline. Also add
a few test cases for these error edge cases.
While at it, make use of T.Run, which was useful in debugging
Tree.pipeline via print statements.
Fixes #28437.
Change-Id: Idc9966bf643f0f3bc1b052620357e5b0aa2022ea
Reviewed-on: https://go-review.googlesource.com/c/145282
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
|
|
There's precedent in handling panics that happen in functions called
from the standard library. For example, if a fmt.Formatter
implementation fails, fmt will absorb the panic into the output text.
Recovering panics is useful, because otherwise one would have to wrap
some Template.Execute calls with a recover. For example, if there's a
chance that the callbacks may panic, or if part of the input data is nil
when it shouldn't be.
In particular, it's a common confusion amongst new Go developers that
one can call a method on a nil receiver. Expecting text/template to
error on such a call, they encounter a long and confusing panic if the
method expects the receiver to be non-nil.
To achieve this, introduce safeCall, which takes care of handling error
returns as well as recovering panics. Handling panics in the "call"
function isn't strictly necessary, as that func itself is run via
evalCall. However, this makes the code more consistent, and can allow
for better context in panics via the "call" function.
Finally, add some test cases with a mix of funcs, methods, and func
fields that panic.
Fixes #28242.
Change-Id: Id67be22cc9ebaedeb4b17fa84e677b4b6e09ec67
Reviewed-on: https://go-review.googlesource.com/c/143097
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes #27930
Change-Id: I31ad3fdb74d74152268c59ae4c651cc4c8c1716d
Reviewed-on: https://go-review.googlesource.com/c/142217
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Recent change golang.org/cl/142737 drops the only call site for the
sortKeys function. If it's not in use, it should probably not be there in
the code, lurking and preparing to bite us when someone calls that instead
of the new key sorter in fmtsort, resulting in strange inconsistencies.
Since the function isn't called, this should have no impact.
Related to, but does not fix, #21095.
Change-Id: I4695503ef4d5ce90d989ec952f01ea00cc15c79d
Reviewed-on: https://go-review.googlesource.com/c/143178
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
For easier testing, change the way maps are printed so they
appear in a consistent order between runs. Do this by printing
them in key-sorted order.
To do this, we add a package at the root, internal/fmtsort,
that implements a general mechanism for sorting map keys
regardless of their type. This is a little messy and probably
slow, but formatted printing of maps has never been fast and
is already always reflection-driven.
The rules are:
The ordering rules are more general than with Go's < operator:
- when applicable, nil compares low
- ints, floats, and strings order by <
- NaN compares less than non-NaN floats
- bool compares false before true
- complex compares real, then imag
- pointers compare by machine address
- channel values compare by machine address
- structs compare each field in turn
- arrays compare each element in turn.
- interface values compare first by reflect.Type describing the concrete type
and then by concrete value as described in the previous rules.
The new package is internal because we really do not want
everyone using this to sort things. It is slow, not general, and
only suitable for the subset of types that can be map keys.
Also use the package in text/template, which already had a
weaker version of this mechanism.
This change requires adding a dependency on sort to the fmt
package, but that isn't disruptive to the dependency tree.
Fixes #21095
Change-Id: Ia602115c7de5d95993dbd609611d8bd96e054157
Reviewed-on: https://go-review.googlesource.com/c/142737
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
This behavior is the same as in Go: constants can be coerced to int
and whether overflow occurs depends on how big an int is, but
this surprises people sometimes, so document it again here.
Fixes #25833.
Change-Id: I557995f1a1e8e871b21004953923d16f36cb9037
Reviewed-on: https://go-review.googlesource.com/c/141378
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
I omitted vendor directories and anything necessary for bootstrapping.
(Tested by bootstrapping with Go 1.4)
Updates #27864
Change-Id: I7d9b68d0372d3a34dee22966cca323513ece7e8a
Reviewed-on: https://go-review.googlesource.com/137856
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
First, move the strings.Count logic out of emit, since only itemText
requires that. Use it in those call sites. itemLeftDelim and
itemRightDelim cannot contain newlines, as they're the "{{" and "}}"
tokens.
Secondly, introduce a startLine lexer field so that we don't have to
keep track of it elsewhere. That's also a requirement to move the
strings.Count out of emit, as emit modifies the start position field.
Change-Id: I69175f403487607a8e5b561b3f1916ee9dc3c0c6
Reviewed-on: https://go-review.googlesource.com/132275
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
lexRawQuote already uses the next method, which keeps track of newlines
on a character by character basis. Adding up newlines in emit again
results in the newlines being counted twice, which can mean bad position
information in error messages.
Fix that, and add a test.
Fixes #27319.
Change-Id: Id803be065c541412dc808d388bc6d8a86a0de41e
Reviewed-on: https://go-review.googlesource.com/131996
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This turns
panic: function name is not a valid identifier
into
panic: function name "" is not a valid identifier
and also makes it consistent with the func signature check.
This CL also makes the testBadFuncName func a test helper.
Change-Id: Id967cb61ac28228de81e1cd76a39f5195a5ebd11
Reviewed-on: https://go-review.googlesource.com/130998
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Previously Scanner would allow float literals like "1.5e" and "1e+"
that weren't actually valid Go float literals, and also not valid
when passed to ParseFloat. This commit fixes that behaviour to match
the documentation ("recognizes all literals as defined by the Go
language specification"), and Scanner emits an error in these cases.
Fixes #26374
Change-Id: I6855402ea43febb448c6dff105b9578e31803c01
Reviewed-on: https://go-review.googlesource.com/129095
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
CL 95215 changed text/template so that untyped nil arguments were no
longer ignored, but were instead passed to functions as expected.
This had an unexpected effect on html/template, where all data is
implicitly passed to functions: originally untyped nil arguments were
not passed and were thus effectively ignored, but after CL 95215 they
were passed and were printed, typically as an escaped version of "<nil>".
This CL restores some of the behavior of html/template by ignoring
untyped nil arguments passed implicitly to escaper functions.
While eliminating one change to html/template relative to earlier
releases, this unfortunately introduces a different one: originally
values of interface type with the value nil were printed as an escaped
version of "<nil>". With this CL they are ignored as though they were
untyped nil values. My judgement is that this is a less common case.
We'll see.
This CL adds some tests of typed and untyped nil values to
html/template and text/template to capture the current behavior.
Updates #18716
Fixes #25875
Change-Id: I5912983ca32b31ece29e929e72d503b54d7b0cac
Reviewed-on: https://go-review.googlesource.com/121815
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fix a comment that misrepresented the Assign operator (=).
Rename: colon-equals -> equals.
Change-Id: I405b8acfb0bcd1b176a91a95f9bfb61a4e85815f
GitHub-Last-Rev: aec0bf594c63d7b015f88f97f9953ade976817a4
GitHub-Pull-Request: golang/go#26112
Reviewed-on: https://go-review.googlesource.com/121416
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
golang.org/cl/84480 altered the API for the parse package for
clarity and consistency. However, the changes also broke the
API for consumers of the package. This CL reverts the API
to the previous spelling, adding only a single new exported
symbol.
Fixes #25968
Change-Id: Ieb81054b61eeac7df3bc3864ef446df43c26b80f
Reviewed-on: https://go-review.googlesource.com/120355
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
These were added in CL 106979. I got them wrong.
They were fixed in CL 111643. They were still wrong.
Hopefully this change will be the last fix.
With this fix, CL 106979 is allocation-neutral for BenchmarkRagged.
The performance results for BenchmarkPyramid reported in CL 111643 stand.
Change-Id: Id6a522e6602e5df31f504adf5a3bec9969c18649
Reviewed-on: https://go-review.googlesource.com/116015
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Fixes #23675
Change-Id: I78e13d1ca90400e4dd48674b93bb6e2e30718d97
GitHub-Last-Rev: f2b3a59d2bd92f28fc06360e7920c37b9da0af01
GitHub-Pull-Request: golang/go#25287
Reviewed-on: https://go-review.googlesource.com/112037
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
\f triggers a flush.
This is used (by gofmt, among others) to indicate that
the current aligned segment has ended.
When flushed, it is unlikely that the previous line is
in fact a good predictor of the upcoming line,
so stop treating it as such.
No performance impact on the existing benchmarks,
which do not perform any flushes.
Change-Id: Ifdf3e6d4600713c90db7b51a10e429d9260dc08c
Reviewed-on: https://go-review.googlesource.com/111644
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
These were added in CL 106979. They were wrong.
The correct impact of CL 106979 on these benchmarks is:
name old time/op new time/op delta
Pyramid/10-8 6.22µs ± 1% 5.68µs ± 0% -8.78% (p=0.000 n=15+13)
Pyramid/100-8 275µs ± 1% 255µs ± 1% -7.30% (p=0.000 n=15+13)
Pyramid/1000-8 25.6ms ± 1% 24.8ms ± 1% -2.88% (p=0.000 n=15+14)
Ragged/10-8 8.98µs ± 1% 6.74µs ± 0% -24.98% (p=0.000 n=15+14)
Ragged/100-8 85.3µs ± 0% 57.5µs ± 1% -32.51% (p=0.000 n=13+15)
Ragged/1000-8 847µs ± 1% 561µs ± 1% -33.85% (p=0.000 n=14+15)
name old alloc/op new alloc/op delta
Pyramid/10-8 4.74kB ± 0% 4.88kB ± 0% +3.04% (p=0.000 n=15+15)
Pyramid/100-8 379kB ± 0% 411kB ± 0% +8.50% (p=0.000 n=15+12)
Pyramid/1000-8 35.3MB ± 0% 41.6MB ± 0% +17.68% (p=0.000 n=15+15)
Ragged/10-8 4.82kB ± 0% 1.82kB ± 0% -62.13% (p=0.000 n=15+15)
Ragged/100-8 45.4kB ± 0% 1.8kB ± 0% -95.98% (p=0.000 n=15+15)
Ragged/1000-8 449kB ± 0% 2kB ± 0% -99.59% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
Pyramid/10-8 50.0 ± 0% 35.0 ± 0% -30.00% (p=0.000 n=15+15)
Pyramid/100-8 704 ± 0% 231 ± 0% -67.19% (p=0.000 n=15+15)
Pyramid/1000-8 10.0k ± 0% 2.1k ± 0% -79.52% (p=0.000 n=15+15)
Ragged/10-8 60.0 ± 0% 19.0 ± 0% -68.33% (p=0.000 n=15+15)
Ragged/100-8 511 ± 0% 19 ± 0% -96.28% (p=0.000 n=15+15)
Ragged/1000-8 5.01k ± 0% 0.02k ± 0% -99.62% (p=0.000 n=15+15)
This is an improvement over what was originally reported,
except the increase in alloc/op for the Pyramid benchmarks.
Change-Id: Ib2617c1288ce35f2c78e0172533d231b86e48bc2
Reviewed-on: https://go-review.googlesource.com/111643
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The general policy for the current state of js/wasm is that it only
has to support tests that are also supported by nacl.
The test nilptr3.go makes assumptions about which nil checks can be
removed. Since WebAssembly does not signal on reading a null pointer,
all nil checks have to be explicit.
Updates #18892
Change-Id: I06a687860b8d22ae26b1c391499c0f5183e4c485
Reviewed-on: https://go-review.googlesource.com/110096
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Make comment example consistent with its description.
Fixes #24767
Change-Id: Icff54b489040b1ce66c644a21343c6576304cf75
Reviewed-on: https://go-review.googlesource.com/107663
Reviewed-by: Rob Pike <r@golang.org>
|
|
The tabwriter tracks cells on a line-by-line basis.
This can be memory-hungry when working with large input.
This change adds two optimizations.
First, when there's an existing cell slice for a line,
don't overwrite it by appending.
This helps when re-using a Writer,
or when the output is broken into groups,
e.g. by a blank line.
We now re-use that existing cell slice.
Second, we predict that the number of cells in a line
will probably match those of the previous line,
since tabwriter is most often used to format tables.
This has a noticeable impact on cmd/objdump (#24725).
It reduces allocated space by about 55%.
It also speeds it up some.
Using "benchcmd -n 10 Objdump go tool objdump `which go`":
name old time/op new time/op delta
ObjdumpCompile 9.03s ± 1% 8.51s ± 1% -5.81% (p=0.000 n=10+10)
It might also imaginably speed up gofmt on some
large machine-generated code.
name old time/op new time/op delta
Table/1x10/new-8 2.89µs ± 1% 2.39µs ± 1% -17.39% (p=0.000 n=13+14)
Table/1x10/reuse-8 2.13µs ± 1% 1.29µs ± 2% -39.58% (p=0.000 n=14+15)
Table/1x1000/new-8 203µs ± 0% 147µs ± 1% -27.45% (p=0.000 n=13+14)
Table/1x1000/reuse-8 194µs ± 1% 113µs ± 2% -42.01% (p=0.000 n=14+15)
Table/1x100000/new-8 33.1ms ± 1% 27.5ms ± 2% -17.08% (p=0.000 n=15+15)
Table/1x100000/reuse-8 22.0ms ± 3% 11.8ms ± 1% -46.23% (p=0.000 n=14+12)
Table/10x10/new-8 8.51µs ± 0% 6.52µs ± 1% -23.48% (p=0.000 n=13+15)
Table/10x10/reuse-8 7.41µs ± 0% 4.59µs ± 3% -38.03% (p=0.000 n=14+15)
Table/10x1000/new-8 749µs ± 0% 521µs ± 1% -30.39% (p=0.000 n=12+15)
Table/10x1000/reuse-8 732µs ± 1% 448µs ± 2% -38.79% (p=0.000 n=15+14)
Table/10x100000/new-8 102ms ± 2% 74ms ± 2% -28.05% (p=0.000 n=14+15)
Table/10x100000/reuse-8 96.2ms ± 4% 55.4ms ± 3% -42.36% (p=0.000 n=15+15)
Table/100x10/new-8 50.3µs ± 1% 43.3µs ± 1% -13.87% (p=0.000 n=14+15)
Table/100x10/reuse-8 47.6µs ± 1% 36.1µs ± 1% -24.09% (p=0.000 n=14+14)
Table/100x1000/new-8 5.17ms ± 1% 4.11ms ± 1% -20.40% (p=0.000 n=14+13)
Table/100x1000/reuse-8 5.00ms ± 1% 3.73ms ± 1% -25.46% (p=0.000 n=14+14)
Table/100x100000/new-8 654ms ± 2% 531ms ± 2% -18.86% (p=0.000 n=13+14)
Table/100x100000/reuse-8 709ms ± 1% 505ms ± 2% -28.77% (p=0.000 n=12+15)
Pyramid/10-8 4.22µs ± 1% 4.21µs ± 1% ~ (p=0.067 n=14+14)
Pyramid/100-8 378µs ± 0% 378µs ± 0% +0.17% (p=0.022 n=13+13)
Pyramid/1000-8 133ms ± 3% 132ms ± 3% ~ (p=0.148 n=15+15)
Ragged/10-8 6.10µs ± 0% 5.16µs ± 0% -15.38% (p=0.000 n=14+15)
Ragged/100-8 54.5µs ± 0% 43.8µs ± 0% -19.59% (p=0.000 n=14+15)
Ragged/1000-8 532µs ± 0% 424µs ± 0% -20.25% (p=0.000 n=14+14)
name old alloc/op new alloc/op delta
Table/1x10/new-8 1.76kB ± 0% 1.52kB ± 0% -13.64% (p=0.000 n=15+15)
Table/1x10/reuse-8 800B ± 0% 0B -100.00% (p=0.000 n=15+15)
Table/1x1000/new-8 131kB ± 0% 99kB ± 0% -24.30% (p=0.000 n=15+15)
Table/1x1000/reuse-8 80.0kB ± 0% 0.0kB ± 0% -99.99% (p=0.000 n=15+15)
Table/1x100000/new-8 23.1MB ± 0% 19.9MB ± 0% -13.85% (p=0.000 n=15+15)
Table/1x100000/reuse-8 8.30MB ± 0% 0.20MB ± 0% -97.60% (p=0.000 n=13+12)
Table/10x10/new-8 8.94kB ± 0% 5.06kB ± 0% -43.47% (p=0.000 n=15+15)
Table/10x10/reuse-8 7.52kB ± 0% 0.00kB -100.00% (p=0.000 n=15+15)
Table/10x1000/new-8 850kB ± 0% 387kB ± 0% -54.50% (p=0.000 n=13+15)
Table/10x1000/reuse-8 752kB ± 0% 0kB ± 0% -99.98% (p=0.000 n=13+15)
Table/10x100000/new-8 95.7MB ± 0% 49.3MB ± 0% -48.50% (p=0.000 n=14+15)
Table/10x100000/reuse-8 76.2MB ± 0% 2.5MB ± 0% -96.77% (p=0.000 n=13+15)
Table/100x10/new-8 66.3kB ± 0% 38.0kB ± 0% -42.65% (p=0.000 n=15+15)
Table/100x10/reuse-8 61.3kB ± 0% 0.0kB -100.00% (p=0.000 n=15+15)
Table/100x1000/new-8 6.69MB ± 0% 3.25MB ± 0% -51.37% (p=0.000 n=15+15)
Table/100x1000/reuse-8 6.13MB ± 0% 0.01MB ± 0% -99.89% (p=0.000 n=15+15)
Table/100x100000/new-8 684MB ± 0% 340MB ± 0% -50.29% (p=0.000 n=14+15)
Table/100x100000/reuse-8 648MB ± 0% 170MB ± 0% -73.78% (p=0.000 n=14+13)
Pyramid/10-8 4.40kB ± 0% 4.40kB ± 0% ~ (all equal)
Pyramid/100-8 652kB ± 0% 652kB ± 0% ~ (p=0.715 n=15+15)
Pyramid/1000-8 96.7MB ± 0% 96.7MB ± 0% ~ (p=0.084 n=15+14)
Ragged/10-8 5.17kB ± 0% 4.51kB ± 0% -12.69% (p=0.000 n=15+15)
Ragged/100-8 50.2kB ± 0% 41.1kB ± 0% -18.04% (p=0.000 n=15+15)
Ragged/1000-8 492kB ± 0% 401kB ± 0% -18.61% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
Table/1x10/new-8 29.0 ± 0% 21.0 ± 0% -27.59% (p=0.000 n=15+15)
Table/1x10/reuse-8 20.0 ± 0% 0.0 -100.00% (p=0.000 n=15+15)
Table/1x1000/new-8 2.02k ± 0% 1.02k ± 0% -49.38% (p=0.000 n=15+15)
Table/1x1000/reuse-8 2.00k ± 0% 0.00k -100.00% (p=0.000 n=15+15)
Table/1x100000/new-8 200k ± 0% 100k ± 0% -49.98% (p=0.000 n=15+15)
Table/1x100000/reuse-8 200k ± 0% 1k ± 0% -99.50% (p=0.000 n=14+15)
Table/10x10/new-8 66.0 ± 0% 31.0 ± 0% -53.03% (p=0.000 n=15+15)
Table/10x10/reuse-8 50.0 ± 0% 0.0 -100.00% (p=0.000 n=15+15)
Table/10x1000/new-8 5.03k ± 0% 1.04k ± 0% -79.36% (p=0.000 n=15+15)
Table/10x1000/reuse-8 5.00k ± 0% 0.00k -100.00% (p=0.000 n=15+15)
Table/10x100000/new-8 500k ± 0% 100k ± 0% -79.99% (p=0.000 n=15+15)
Table/10x100000/reuse-8 500k ± 0% 5k ± 0% -99.00% (p=0.000 n=15+15)
Table/100x10/new-8 102 ± 0% 40 ± 0% -60.78% (p=0.000 n=15+15)
Table/100x10/reuse-8 80.0 ± 0% 0.0 -100.00% (p=0.000 n=15+15)
Table/100x1000/new-8 8.04k ± 0% 1.05k ± 0% -86.91% (p=0.000 n=15+15)
Table/100x1000/reuse-8 8.00k ± 0% 0.00k ± 0% -99.98% (p=0.000 n=15+15)
Table/100x100000/new-8 800k ± 0% 100k ± 0% -87.49% (p=0.000 n=15+12)
Table/100x100000/reuse-8 800k ± 0% 50k ± 0% -93.74% (p=0.000 n=14+13)
Pyramid/10-8 20.0 ± 0% 20.0 ± 0% ~ (all equal)
Pyramid/100-8 50.0 ± 0% 50.0 ± 0% ~ (all equal)
Pyramid/1000-8 109 ± 0% 109 ± 0% ~ (all equal)
Ragged/10-8 54.0 ± 0% 34.0 ± 0% -37.04% (p=0.000 n=15+15)
Ragged/100-8 422 ± 0% 188 ± 0% -55.45% (p=0.000 n=15+15)
Ragged/1000-8 4.03k ± 0% 1.66k ± 0% -58.80% (p=0.000 n=15+15)
Change-Id: I0c0a392b02d5148a0a4b8ad4eaf98fa343980962
Reviewed-on: https://go-review.googlesource.com/106979
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Fixes #24791
Change-Id: I62ac17313e6e09796586911d88191a36d67f9aa1
Reviewed-on: https://go-review.googlesource.com/106115
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Noticed that we can simply use a []byte slice while investigating
a separate issue. Did the obvious simplification.
Change-Id: I921ebbb42135b5f1a10109236ceb9ae6e94ae7e2
Reviewed-on: https://go-review.googlesource.com/104757
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Variables can be declared and shadowing is supported, but modifying
existing variables via assignments was not available.
This meant that modifying a variable from a nested block was not
possible:
{{ $v := "init" }}
{{ if true }}
{{ $v := "changed" }}
{{ end }}
v: {{ $v }} {{/* "init" */}}
Introduce the "=" assignment token, such that one can now do:
{{ $v := "init" }}
{{ if true }}
{{ $v = "changed" }}
{{ end }}
v: {{ $v }} {{/* "changed" */}}
To avoid confusion, rename PipeNode.Decl to PipeNode.Vars, as the
variables may not always be declared after this change. Also change a
few other names to better reflect the added ambiguity of variables in
pipelines.
Modifying the text/template/parse package in a backwards incompatible
manner is acceptable, given that the package godoc clearly states that
it isn't intended for general use. It's the equivalent of an internal
package, back when internal packages didn't exist yet.
To make the changes to the parse package sit well with the cmd/api test,
update except.txt with the changes that we aren't worried about.
Fixes #10608.
Change-Id: I1f83a4297ee093fd45f9993cebb78fc9a9e81295
Reviewed-on: https://go-review.googlesource.com/84480
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Added examples for use of Mode, Whitespace, and IsIdentRune properties.
Fixes #23768
Change-Id: I2528e14fde63a4476f3c25510bf0c5b73f38ba5d
Reviewed-on: https://go-review.googlesource.com/93199
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Fixes #23520
Change-Id: Ia834819f3260691a1a0181034ef4b4b945965688
Reviewed-on: https://go-review.googlesource.com/94761
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
This follows up CL95235
Change-Id: I62652654e5bb46d2f8f37af468e1fbcc1835bb8a
Reviewed-on: https://go-review.googlesource.com/95295
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
It's always nil, so simplify its signature. Found with unparam.
Change-Id: I45dd0f868ec2f5de98a970776be686417c8d73b6
Reviewed-on: https://go-review.googlesource.com/95235
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
reflect.Value is a struct and does not have a kind nor any flag for
untyped nils. As a result, it is tricky to differentiate when we're
missing a value, from when we have one but it is untyped nil.
We could start using *reflect.Value instead, to add one level of
indirection, using nil for missing values and new(reflect.Value) for
untyped nils. However, that is a fairly invasive change, and would also
mean unnecessary allocations.
Instead, use a special reflect.Value that depicts when a value is
missing. This is the case for the "final" reflect.Value in multiple
scenarios, such as the start of a pipeline. Give it a specific,
unexported type too, to make sure it cannot be mistaken for any other
valid value.
Finally, replace "final.IsValid()" with "final != missingVal", since
final.IsValid() will be false when final is an untyped nil.
Also add a few test cases, all different variants of the untyped nil
versus missing value scenario.
Fixes #18716.
Change-Id: Ia9257a84660ead5a7007fd1cced7782760b62d9d
Reviewed-on: https://go-review.googlesource.com/95215
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
