delta/go-git.git/test, branch dev.boringcrypto

cmd/compile/internal/syntax: parser to accept ~x as unary expression

2022-04-26T02:19:42+00:00

Accept ~x as ordinary unary expression in the parser but recognize
such expressions as invalid in the type checker.

This change opens the door to recognizing complex type constraint
literals such as `*E|~int` in `[P *E|~int]` and parse them correctly
instead of reporting a parse error because `P*E|~int` syntactically
looks like an incorrect array length expression (binary expression
where the RHS of | is an invalid unary expression ~int).

As a result, the parser is more forgiving with expressions but the
type checker will reject invalid uses as before.

We could pass extra information into the binary/unary expression
parse functions to prevent the use of ~ in invalid situations but
it doesn't seem worth the trouble. In fact it may be advantageous
to allow a more liberal expression syntax especially in the presence
of errors (better parser synchronization after an error).

Preparation for fixing #49482.

Change-Id: I119e8bd9445dfa6460fcd7e0658e3554a34b2769
Reviewed-on: https://go-review.googlesource.com/c/go/+/402255
Run-TryBot: Robert Griesemer 
TryBot-Result: Gopher Robot 
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Robert Griesemer 
Auto-Submit: Robert Griesemer

test/typeparam: fix copyright message

2022-04-21T23:41:49+00:00

Change-Id: Ia0a4be56d4e1fbfc73e6ce24f01a658c89a74adb
GitHub-Last-Rev: dd95e50c4b37a031d3ee852bbb7487f748526562
GitHub-Pull-Request: golang/go#52393
Reviewed-on: https://go-review.googlesource.com/c/go/+/400694
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Ian Lance Taylor 
Auto-Submit: Ian Lance Taylor 
TryBot-Result: Gopher Robot 
Reviewed-by: Dmitri Shuralyov

cmd/compile: add //go:uintptrkeepalive

2022-04-21T18:06:38+00:00

This CL exports the existing ir.UintptrKeepAlive via the new directive
//go:uintptrkeepalive. This makes the compiler insert KeepAlives for
pointers converted to uintptr in calls, keeping them alive for the
duration of the call.

//go:uintptrkeepalive requires //go:nosplit, as stack growth can't
handle these arguments (it cannot know which are pointers). We currently
check this on the immediate function, but the actual restriction applies
to all transitive calls.

The existing //go:uintptrescapes is an extension of
//go:uintptrkeepalive which forces pointers to escape to the heap, thus
eliminating the stack growth issue.

This pragma is limited to the standard library.

For #51087

Change-Id: If9a19d484d3561b4219e5539b70c11a3cc09391e
Reviewed-on: https://go-review.googlesource.com/c/go/+/388095
Run-TryBot: Michael Pratt 
Reviewed-by: Matthew Dempsky 
TryBot-Result: Gopher Robot

test: rename live_syscall.go to live_uintptrkeepalive.go

2022-04-21T18:06:26+00:00

CL 388095 will change this file significantly. Move it preemptively to
ensure git tracks the move properly.

For #51087

Change-Id: I1408aecf8675723041b64e54cf44cdec38cc655c
Reviewed-on: https://go-review.googlesource.com/c/go/+/388094
Run-TryBot: Michael Pratt 
Reviewed-by: Matthew Dempsky 
Reviewed-by: David Chase 
TryBot-Result: Gopher Robot

cmd/compile/internal/types2: use correct value of iota

2022-04-19T23:20:21+00:00

Fixes #52438.

Change-Id: I5cbf8c448dba037e9e0c5fe8f209401d6bf7d43f
Reviewed-on: https://go-review.googlesource.com/c/go/+/401134
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Robert Griesemer

cmd/link: faster algorithm for nosplit stack checking, better errors

2022-04-19T15:59:26+00:00

The linker performs a global analysis of all nosplit call chains to
check they fit in the stack space ensured by splittable functions.
That analysis has two problems right now:

1. It's inefficient. It performs a top-down analysis, starting with
every nosplit function and the nosplit stack limit and walking *down*
the call graph to compute how much stack remains at every call. As a
result, it visits the same functions over and over, often with
different remaining stack depths. This approach is historical: this
check was originally written in C and this approach avoided the need
for any interesting data structures.

2. If some call chain is over the limit, it only reports a single call
chain. As a result, if the check does fail, you often wind up playing
whack-a-mole by guessing where the problem is in the one chain, trying
to reduce the stack size, and then seeing if the link works or reports
a different path.

This CL completely rewrites the nosplit stack check. It now uses a
bottom-up analysis, computing the maximum stack height required by
every function's call tree. This visits every function exactly once,
making it much more efficient. It uses slightly more heap space for
intermediate storage, but still very little in the scheme of the
overall link. For example, when linking cmd/go, the new algorithm
virtually eliminates the time spent in this pass, and reduces overall
link time:

           │   before    │                after                │
           │   sec/op    │   sec/op     vs base                │
Dostkcheck   7.926m ± 4%   1.831m ± 6%  -76.90% (p=0.000 n=20)
TotalTime    301.3m ± 1%   296.4m ± 3%   -1.62% (p=0.040 n=20)

           │    before    │                 after                  │
           │     B/op     │     B/op       vs base                 │
Dostkcheck   40.00Ki ± 0%   212.15Ki ± 0%  +430.37% (p=0.000 n=20)

Most of this time is spent analyzing the runtime, so for larger
binaries, the total time saved is roughly the same, and proportionally
less of the overall link.

If the new implementation finds an error, it redoes the analysis,
switching to preferring quality of error reporting over performance.
For error reporting, it computes stack depths top-down (like the old
algorithm), and reports *all* paths that are over the stack limit,
presented as a tree for compactness. For example, this is the output
from a simple test case from test/nosplit with two over-limit paths
from f1:

        main.f1: nosplit stack overflow
        main.f1
            grows 768 bytes, calls main.f2
                grows 56 bytes, calls main.f4
                    grows 48 bytes
                    80 bytes over limit
            grows 768 bytes, calls main.f3
                grows 104 bytes
                80 bytes over limit

While we're here, we do a few nice cleanups:

- We add a debug output flag, which will be useful for understanding
  what our nosplit chains look like and which ones are close to
  running over.

- We move the implementation out of the fog of lib.go to its own file.

- The implementation is generally more Go-like and less C-like.

Change-Id: If1ab31197f5215475559b93695c44a01bd16e276
Reviewed-on: https://go-review.googlesource.com/c/go/+/398176
Run-TryBot: Austin Clements 
Reviewed-by: Than McIntosh 
Reviewed-by: Cherry Mui 
TryBot-Result: Gopher Robot

test/nosplit: add more complicated recursion tests

2022-04-19T15:59:25+00:00

Change-Id: I301ed8bcc93f31147d247e60a7aab8ed42421bbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/398175
Run-TryBot: Austin Clements 
Reviewed-by: Cherry Mui 
TryBot-Result: Gopher Robot

test/nosplit: apply stack limit adjustment in the right place

2022-04-19T15:59:24+00:00

The nosplit test was originally written when the stack limit was a
mere 128 bytes. Now it's much larger, but rather than rewriting all of
the tests, we apply a hack to just add the extra space into the stack
frames of the existing tests.

Unfortunately, we add it in the wrong place. The extra space should be
added just once per chain of nosplit functions, but instead we add it
to every frame that appears first on a line in the test's little
script language. This means that for tests like

    start 0 call f1
    f1 16 nosplit call f2
    f2 16 nosplit call f3
    f3 16 nosplit call f4
    f4 16 nosplit call f5
    f5 16 nosplit call f6
    f6 16 nosplit call f7
    f7 16 nosplit call f8
    f8 16 nosplit call end
    end 1000
    REJECT

we add 672 bytes to *every* frame, meaning that we wind up way over
the stack limit by the end of the stanza, rather than just a little as
originally intended.

Fix this by instead adding the extra space to the first nosplit
function in a stanza. This isn't perfect either, since we could have a
nosplit -> split -> nosplit chain, but it's the best we can do without
a graph analysis.

Change-Id: Ibf156c68fe3eb1b64a438115f4a17f1a6c7e2bd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/398174
Run-TryBot: Austin Clements 
Reviewed-by: Cherry Mui 
TryBot-Result: Gopher Robot

cmd/compile: add jump table codegen test

2022-04-14T21:16:29+00:00

Change-Id: Ic67f676f5ebe146166a0d3c1d78a802881320e49
Reviewed-on: https://go-review.googlesource.com/c/go/+/400375
Run-TryBot: Keith Randall 
TryBot-Result: Gopher Robot 
Reviewed-by: Cherry Mui 
Reviewed-by: Keith Randall

cmd/compile: constant-fold switches early in compilation

2022-04-14T19:37:30+00:00

So that the inliner knows all the other cases are dead and doesn't
accumulate any cost for them.

The canonical case for this is switching on runtime.GOOS, which occurs
several places in the stdlib.

Fixes #50253

Change-Id: I44823aaebb6c1b03c9b0c12d10086db81954350f
Reviewed-on: https://go-review.googlesource.com/c/go/+/399694
Run-TryBot: Keith Randall 
Reviewed-by: Cuong Manh Le 
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Russ Cox 
TryBot-Result: Gopher Robot