delta/go-git.git/src/cmd, branch dev.boringcrypto

[dev.boringcrypto] cmd/compile: remove the awful boringcrypto kludge

2022-04-29T14:24:53+00:00

CL 60271 introduced this “AwfulBoringCryptoKludge.”
iant approved that CL saying “As long as it stays out of master...”

Now that the rsa and ecdsa code uses boring.Cache, the
“boring unsafe.Pointer” fields are gone from the key structs, and this
code is no longer needed. So delete it.

With the kludge deleted, we are one step closer to being able to merge
dev.boringcrypto into master.

For #51940.

Change-Id: Ie549db14b0b699c306dded2a2163f18f31d45530
Reviewed-on: https://go-review.googlesource.com/c/go/+/395884
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Ian Lance Taylor

[dev.boringcrypto] cmd/dist: default to use of boringcrypto

2022-04-29T14:23:25+00:00

The dev.boringcrypto branch has historically forced use of boringcrypto
with no additional configuration flags. The previous CL undid that.
This CL redoes it, so that direct uses of dev.boringcrypto don't lapse
unexpectedly into not having boringcrypto enabled.

When dev.boringcrypto is merged into master, we will undo this change
as part of the merge, so that the only final difference between master
and dev.boringcrypto will be this CL.

For #51940.

Change-Id: I816593a0b30b4e71093a7da9451bae7807d7167e
Reviewed-on: https://go-review.googlesource.com/c/go/+/402597
Run-TryBot: Russ Cox 
Reviewed-by: Ian Lance Taylor 
TryBot-Result: Gopher Robot

[dev.boringcrypto] all: add boringcrypto build tags

2022-04-29T14:23:22+00:00

A plain make.bash in this tree will produce a working,
standard Go toolchain, not a BoringCrypto-enabled one.

The BoringCrypto-enabled one will be created with:

	GOEXPERIMENT=boringcrypto ./make.bash

For #51940.

Change-Id: Ia9102ed993242eb1cb7f9b93eca97e81986a27b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/395881
Run-TryBot: Russ Cox 
Reviewed-by: Ian Lance Taylor 
TryBot-Result: Gopher Robot 
Reviewed-by: Ian Lance Taylor

[dev.boringcrypto] cmd/go: pass dependency syso to cgo too

2022-04-29T14:23:21+00:00

Proposal #42477 asked for a way to apply conditional build tags
to syso files (which have no source code to hold //go:build lines).

We ended up suggesting that the standard answer should be to
put the syso in its own package and then import that package from
a source file that is itself conditionally compiled.

A followup comment on that issue pointed out a problem that I did
not understand until I tried to use this approach myself: the cgo
build fails by default, because the link step only uses syso files from
the current package. You have to override this explicitly by arranging
to pass a “ignore unresolved symbols” flag to the host linker.
Many users will not know how to do this.
(I don't know how to do this off the top of my head.)

If we want users to use this approach, we should make it work better.
This CL does that, by including the syso files from dependencies of
the current package in the link step.

For #51940.

Change-Id: I53a0371b2df17e39a000a645b7686daa6a98722d
Reviewed-on: https://go-review.googlesource.com/c/go/+/402596
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Russ Cox 
TryBot-Result: Gopher Robot

[dev.boringcrypto] cmd: use notsha256 instead of md5, sha1, sha256

2022-04-29T14:23:19+00:00

When we add GOEXPERIMENT=boringcrypto, the bootstrap process
will not converge if the compiler itself depends on the boringcrypto
cgo-based implementations of sha1 and sha256.

Using notsha256 avoids boringcrypto and makes bootstrap converge.
Removing md5 is not strictly necessary but it seemed worthwhile to
be consistent.

For #51940.

Change-Id: Iba649507e0964d1a49a1d16e463dd23c4e348f14
Reviewed-on: https://go-review.googlesource.com/c/go/+/402595
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Russ Cox 
TryBot-Result: Gopher Robot

[dev.boringcrypto] cmd/internal/notsha256: add new package

2022-04-29T14:23:17+00:00

Package notsha256 implements the NOTSHA256 hash,
defined as bitwise NOT of SHA-256.

It will be used from the Go compiler toolchain where an
arbitrary hash is needed and the code currently reaches
for MD5, SHA1, or SHA256. The problem with all of those
is that when we add GOEXPERIMENT=boringcrypto, the
bootstrap process will not converge if the compiler itself
depends on the boringcrypto cgo code.
Using notsha256 avoids boringcrypto.

It is possible that I don't fully understand the convergence
problem and that there is a way to make the compiler converge
when using cgo, but keeping cgo out of the compiler seems safest.
It also makes clear that (except for the hack in codesign)
the code using this package doesn't care which hash is used.

For #51940.

Change-Id: Ie7c661183eacf8413a9d2074c96cbb9361e125ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/402594
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Russ Cox 
TryBot-Result: Gopher Robot

[dev.boringcrypto] all: merge master into dev.boringcrypto

2022-04-27T18:09:28+00:00

Change-Id: Ic5f71c04f08c03319c043f35be501875adb0a3b0

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

cmd/compile: fix the missing size for FuncInfoSym

2022-04-25T23:45:52+00:00

Change-Id: I46543e188bf25384e529a9d5a3095033ac618bbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/402057
Run-TryBot: Cherry Mui 
TryBot-Result: Gopher Robot 
Reviewed-by: Cherry Mui 
Reviewed-by: Ian Lance Taylor 
Auto-Submit: Ian Lance Taylor

cmd/dist: add maymorestack tests

2022-04-25T18:12:08+00:00

These tests run the runtime, reflect, and sync package tests with the
two maymorestack hooks we have.

These tests only run on the longtest builders (or with
GO_TEST_SHORT=false) because we're running the runtime test two
additional times and the mayMoreStackMove hook makes it about twice as
slow (~230 seconds).

To run just these tests by hand, do

  GO_TEST_SHORT=false go tool dist test -run mayMoreStack

Updates #48297.

This detected #49354, which was found as a flake on the dashboard, but
was reliably reproducible with these tests; and #49395.

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