<placeholder>

<placeholder>

<placeholder>

<placeholder>

"I prefer passing the additional capacity" So when discussing further should it be assumed the proposal means the hint is to be used for additional capacity?

Can you elaborate what that means for the current hash map implementation. e.g. is the hint making sure there is at least that much open slots somewhere in the map buckets including overflow buckets? Note that depending on hash collisions that does not mean adding that much elements doesnt cause a map growth to happen.

A few questions as the semantics of resize havent been spelled out completly yet:

Assuming: "2: (hint the max cap we want)"

What happens when the hinted at capacity is smaller than the existing capacity: Does the builtin downsize the map?

Does the resize happen for the whole map immediatly or is it done by having each write and delete do a bit of the resize like current map growth?

What happens if the hint provided is larger than a map is allowed to be (exceeding memory limits)?

The map examples given just show adding elements. There would need to be an additional resize call that is trying to more then double the capacity. If its not more than doubling the internal resize mechanism of maps would do the same as the resize on the fly already. A resize will need to also copy all elements to a new map allocation in the current design of maps to grow the map. Spending alot of time in mapassign is not necessarily a sign of map growth but can entirely be generated by just adding elements to a big enough map.

More details can be added in an extra comment or in the top comment.

A possible solution to showing high level usage of different query paths can be achieved by setting profiling labels on the goroutine: https://golang.org/src/runtime/pprof/runtime.go?s=1362:1432#L26

And doing background profiling on the job: https://go-review.googlesource.com/c/go/+/102755

i read soource code about interface hash table. the code say hash use Quadratic Probing. but absolutely not. this is just h +=i not h +=i *i, this is a special design or a bug?

func (t *itabTableType) find(inter *interfacetype, typ *_type) *itab {
	// Implemented using quadratic probing.
	// Probe sequence is h(i) = h0 + i*(i+1)/2 mod 2^k.
	// We're guaranteed to hit all table entries using this probe sequence.
	mask := t.size - 1
	h := itabHashFunc(inter, typ) & mask
	for i := uintptr(1); ; i++ {
		p := (**itab)(add(unsafe.Pointer(&t.entries), h*sys.PtrSize))
		// Use atomic read here so if we see m != nil, we also see
		// the initializations of the fields of m.
		// m := *p
		m := (*itab)(atomic.Loadp(unsafe.Pointer(p)))
		if m == nil {
			return nil
		}
		if m.inter == inter && m._type == typ {
			return m
		}
		h += i
		h &= mask
	}
}

h is increased by and i that is increasing on every iteration. If it would be linear the addition would be by a costant e.g. h += 10.

Heh, @martisch, your instructions to tell the bot to remove the label just removed the label. I don't think it knows how to tell that your comment came before the label was added.

Ack. ordering error on my part ...

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

"With slices you could make a new slice, copy over and assign to the current slice, but with maps/channels it is harder." Is it really that much harder for maps?

new := make(map[X]Y, capacity) for key, value := range old { new[key] = value } If performance is a concern that can solved without a language change: https://github.com/golang/go/issues/26951

/cc @cherrymui @thanm @randall77

See https://github.com/golang/go/issues/40432 for past error handling proposals and associated design problems.

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

I tested a bit around and AT_PLATFORM is mostly not useful as it will only print along the lines of x86_64, aarch64 and similar.

Parsing /proc/cpuinfo will cover all Linux based combinations but unfortunately is more complex than a first glance might suggest. Every architecture on Linux has its own format to store the specify CPU name in differently named fields.

On *BSDs it seems we can get information using sysctl calls that are already implemented in the runtime. I have however not tested how differ across architectures and some *BSDs we may need to implement a sysctlbyname call first if the MIBs are not static.

So in a first iteration it seems we could cover all of x86, amd64 and Linux leaving these not supported initially: aix/ppc64 darwin/arm64 freebsd/arm freebsd/arm64 js/wasm netbsd/arm netbsd/arm64 openbsd/arm openbsd/arm64 plan9/arm windows/arm

Does the computer you build on support SSE2? Otherwise 387 is set. https://github.com/golang/go/blob/24ff2af65e27eed1e8c7f09c21a5ca68fc2e07ab/src/cmd/dist/build.go#L146

Can the problem be reproduced on linux/386 with GO386=387?

@ceseo both are already used on ppc64x: https://github.com/golang/go/blob/8174f7fb2b64c221f7f80c9f7fd4d7eb317ac8bb/src/runtime/os_linux_ppc64x.go#L14 https://github.com/golang/go/blob/8174f7fb2b64c221f7f80c9f7fd4d7eb317ac8bb/src/internal/cpu/cpu_ppc64x.go#L39

@ceseo thanks for pointing this out. I will try to ammend my patch for Linux on all platforms to get AT_PLATFORM from the aux vector. We already use the same mechanism to get HWCAP bits from AT_HWCAP in the auxillary vector.

On all operating systems for 386 and amd64 we can use the CPUID instruction (see http://golang.org/cl/234977) to get the CPU name.

Generally for linux on other architectures /proc/cpuinfo can be used.

For ARM on all operating systems another (more indirect) but not as universal approach can be to read the model and vendor with CPU instructions and then map those to common architecture names for the most common CPUs (e.g. Cortex-A55, Cortex-A77 ...).

With the trust rule changes and account cleanups in https://github.com/golang/go/issues/40699 all rights have been stripped from some accounts.

Please restore rights to run try/slow bots and abandon changes on gerrit for account https://go-review.googlesource.com/q/owner:martisch%2540uos.de

/cc @golang/osp-team

In principle possible with the following caveats that come into my mind:

• to be able to profile all std lib packages one would need to find the first init function and start the profiling in there or add a GODEBUG flag to immediately start profiling (the user wanting to trace might not have the ability to change the std library)
• interrupt driven profiling is sample based and especially for small init functions will require a lot of samples to approximate all init runtimes. we can instead measure with init tracing the same values we are trying to sample with profiling.
• profiling flame graphs or summaries usually do not have any ordering (init foo happend before init bar)

Note: Like #38714 this is not a proposal for the proposal process.

This issue is to discuss and track the addition of support for init function tracing through GODEBUG for ad hoc debugging and profiling of init start times.

Prototype CL: https://go-review.googlesource.com/c/go/+/254659

For the first minimal implementation (future iterations can expand functionality) I think that just showing the package name, start time of the init function, wall clock duration and total heap allocated bytes and number of allocs is sufficient. Later information like module version could be added.

Due to much larger complexity init tracing of plugins is not supported.

Having a more structured format like json output is omitted and likely needs a more holistic approach and decision in unison with adding support for gctrace in json format too.

/cc @mknyszek @aclements @randall77 @prattmic

the generics approach would also not be picked up by stdlib as changing the map implementation would

Could you explain why not? I dont think the std lib is prohibited from using generics once the compiler supports them. Changing the stdlib API if a type is exposed would need to be done with generics and with a new map type and both times break backward compatibility.

If we are going to change it I think go1.16 is a good time as adding a 24byte size class is about to change append capacity allocated already. Batching up these changes up will also batch up some Go code needing to be corrected to not assume capacities grown into by append are consistent between Go versions and we can communicate the changes and potential differences seen between Go versions for multiple CLs together.

Does VMOVQ (SI), AX exist?

c5fa7e06 is vmovq xmm0,QWORD PTR [esi] and https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-2b-manual.pdf seems to suggest it only works with xmm registers.

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

EDIT: just tried []int on play.golang.org and found it rounds up cap to an even number, so wastes 1 half the time.

Im not sure why the additional fields for the cap are considered wasted. Those bytes would be unusable otherwise as the Go gc allocator doesnt e.g. support just reserving three 64bit ints. The next size class that can be allocated are four 64 bit ints. So if append would cut that down to three three 64bit ints it would actually wasted one 64bit int that nothing can ever use until the slice is garbage collected. But making it four 64bit ints that one int can actually be used if one more element is appended. The context needed to understand the append behaviour is that the current Go gc allocator does not support allocating arbitrary sizes of memory for small sizes: https://github.com/golang/go/blob/master/src/runtime/sizeclasses.go

I do not think appends focus should be to be a slice clone mechanism. I do not agree with the idea that because currently its possible to write a slice clone with append in one line and it isn't perfect append needs to change to make it perfect in one line. If a "perfect" slice clone mechanism is needed lets explore how often the nil-ness of slice matters for the copy. I have not seen it come very often and make+copy seems concise enough to me.

If nil vs non-nil is important:

var b []T
if a != nil {
	b = make([]T, len(a))
	copy(b, a)
}

Which nicely conveys explicitly that the case of a == nil is special. For append(src[:0:0], src..) that nil might be special is easily lost as its implicit.

For the more common case I have seen where only length matters (its often an API problem if nil for a slices is handled differently then len(slice) == 0) these to lines are nicely explicit in the meaning and optimised better than append:

b := make([]T, len(a))
copy(b, a)

If a perfect clone is wanted a make with an explicit cap and copy seems the right fit. Using append for that starting from a 0 cap slice seems like a hack to avoid writing more than a one liner.

I agree with @ianlancetaylor that the slice capacities that append produces should not be relied on to be consistent between call sites or versions.

That said it is still odd to me these produce different results and I would like to understand it as both version use the same runtime growslice logic. I suspect there is a subtile difference between the ssa append version for fixed number of elements: https://github.com/golang/go/blob/c489330987eca992cee0bb018a6fdb7ff5401704/src/cmd/compile/internal/gc/ssa.go#L2808

and the walk pass version: https://github.com/golang/go/blob/c489330987eca992cee0bb018a6fdb7ff5401704/src/cmd/compile/internal/gc/walk.go#L2705

if there isnt an error in the example itself.

While https://golang.org/cl/253020 resets the seed when the map clear idiom is used it doesnt reset the seed when maps are emptied to zero elements by just deleting elements without ranging over all the keys or when the pattern for map clear is not triggered.

I think if this is added at all its better to wait for generics.

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.14.7 darwin/amd64

gomobile version gomobile version +973feb4 Sat Aug 1 11:21:45 2020 +0000 (android,ios); androidSDK=/Users/wsli/Library/Android/sdk/platforms/android-30

</pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="/Users/wsli/go/bin" GOCACHE="/Users/wsli/Library/Caches/go-build" GOENV="/Users/wsli/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/wsli/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/Cellar/go/1.14.7/libexec" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.14.7/libexec/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/0j/8lghc3kd7yx2c_1lp9zhc6_h0000gn/T/go-build149931103=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

What did you do?

gomobile bind -v -o $(BINDIR)/xxx.framework -target=ios

What did you expect to see?

frameworks support armv7

What did you see instead?

missing required architecture armv7

ld: warning: Could not find or use auto-linked framework

As seen in the release notes Go 1.15 dropped darwin/arm support: https://golang.org/doc/go1.15#darwin

Issue for dropping support since new IOS versions do not support 32bit arm https://github.com/golang/go/issues/34751

Is there any already?

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues # Asking Questions

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For asking questions, see:

• Stack Overflow with questions tagged "go"

• The Go Forum, a web-based forum

• Gophers Slack, use the invite app for access. The #general channel is a good starting point.

• Go Community on Hashnode with questions and posts tagged with "go"

• The golang-nuts mailing list

• IRC channel #go-nuts on Freenode

You are right! The issue is the VEX prefix and 64bit and protected mode. So I guess we need to guard all vex prefixed instructions with a OSXSAVE check.

But why should it not be used with OSXSAVE? The FMA instruction uses xmm registers that are supported otherwise other SSE/SSE2 instructions wouldnt work either and the CPU says it supports FMA.

The instruction from the dump above that is faulting is: c4 e2 e1 b9 ca vfmadd231sd xmm1,xmm3,xmm2

This uses SSE registers so SSE (required) + FMA (HasFMA) should be enought. There are no AVX registers involved that would require OSXSAVE.

OSXSAVE is not related to MOVUPS. OSXSAVE is only required for AVX.

But what is CR4 on vista?

It seems reading CR4 is priviledged so likely Go wont be able to do that. There seems to be a windows API way to do this: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getenabledxstatefeatures

If there is no easy way to check if Windows supports SSE from Go code and all supported Windows versions of Go work I dont think there will be a fix for this. SSE/SSE2 itself is supported by all amd64 compatible CPUs so it can only be the OS that doesnt support them on amd64.

What is the state of CR4.OSFXSR on Vista? (Note that OSFXSR is not OSXSAVE)

amd64 Go minimal requirement is SSE2. So if sse is not supported yes Go does not work (with or without FMA). The only action I would then see here is to check CR4.OSFXSR on go runtime start and if it is not set then stop right there independent of if FMA is used or not.

FMA can be used without using AVX registers which as far as I understand does not need OSXSAVE. So I think requiring OSXSAVE here is not the right fix as this would disallow code to use FMA with xmm (SSE) registers while the OS does not support saving ymm (AVX) registers.

I think to understand whats happening we need to disassemble go1.14.7 math_test.TestFMA and see what the instruction stream is that is the problem. Maybe VMWare pretends FMA is supported while it isnt but it doesnt seem to be an issue with OSXSAVE if this is reproducable to always error on the same PC.

Please run these two commands in /go1.14.7/src/math/ and post the output: go test -c go tool objdump -s "math_test.TestFMA" math.test

In addition does running: GODEBUG=cpu.fma=off go test in /go1.14.7/src/math/ work?

The above code uses FMA with an xmm register not with an ymm register it should therefore be fine unless Vista doesnt support SSE2.

Note that Windows XP/Vista is not supported by Go 1.14 and 1.15: https://golang.org/doc/install#requirements

To understand the actual issue please give the following information:

• The output of go env
• what is the CPU name and vendor that go is run on
• the stack trace of the crash (so we can identify where the STATUS_ILLEGAL_INSTRUCTION is happening)
• does this reproduce on Windows 7 or newer

Any useful code that uses FMA with ymm registers also needs to check for AVX (e.g. mov instructions to ymm). The HasAVX is only true one HasOSXSAVE is true.

FMA can also be used with xmm registers which does not require HasOSXSAVE.

related to https://groups.google.com/forum/#!topic/golang-nuts/W7e8ugsipqI

Currently, I am not able to list new version of module but for patch only.

For example:

module github.com/test/test

go 1.15

require go.mongodb.org/mongo-driver v1.3.6

I want to know if a new patch version if available (here v1.3.7 and not v1.4.0), but I don't know how to do. The given example here https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies is for direct with minor and patch (I just want patch). And yet, the v1.3.7 has been released (https://pkg.go.dev/mod/go.mongodb.org/[email protected]).

$ go list -u -m all | grep "go.mongodb.org/mongo-driver"
go.mongodb.org/mongo-driver v1.3.6 [v1.4.0]

I want use this in my CI with psampaz/go-mod-outdated from @psampaz but only for patch version with something like :

go list -u -m -json all | go-mod-outdated -update -direct -style markdown -ci

What version of Go are you using (go version)?

1.5.0

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For venues to ask questions, see: https://github.com/golang/go/wiki/Questions

There have been issues now and in the past about bootstrapping Go gc from gccgo being broken #40855, #30771.

Documentation at https://golang.org/doc/install/source#bootstrapFromGccgo suggests that bootstraping from gccgo is supported.

If this is the case I suggest we add a builder for that. To not be blocked on ressources I would assume a build only linux/amd64 builder would suffice to catch bootstrap issues.

/cc @ianlancetaylor @dmitshur

There are pros and cons to every change which need to be carefully evaluated.

To make it a full proposal please take the time to fill in the template so the thought and motivation behind the proposal is understood for discussion and evaluation. https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md

I second the question: where is the procedure documented to generate the CL?

My motivation to knowing is not concerned with generating the update CL but more how to change the process to potentially generate more binary size efficient datastructures for the unicode package.

@Howie66 Please use emoji voting on the orginal issue instead of comments to express sentiment on the proposal https://github.com/golang/go/wiki/NoPlusOne.

Can you explain why is this needed? Is it to save the one line to import "fmt" ?

You have documentation claiming it is supported: https://golang.org/doc/install/source#bootstrapFromGccgo

Thanks for pointing that out. I open another ticket to investigate addition of build testers to make sure this is checked and not getting accidentially broken.

Im not sure bootstrapping gc go with gccgo is supported. Has it worked before? Bootstrapping gc go with newer versions of gc go is supported (up from go 1.4).

With my change, most of your concerns are adressed:

To me now it looks even more like the abandoned handler/check proposal: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

Could you please clarify what the main differences are that makes this proposal stand out it utility and avoiding problems vs the above proposal. This would help the discussion about the intent of the proposal and not reintroducing proposals that are (apart from minor details) the same. Minor details may be important so it is nice to understand the thought process behind them.

Its unclear if this is a question how to change the Go code to make the output match or a proposal that the standard library produce the exact byte by byte output as some other tools for compression.

If it is a question please see https://github.com/golang/go/wiki/Questions for venues to ask questions.

If this is a proposal please clarify why this matters (assuming the current output is otherwise correct according to compression specifications) and why it should be aligned with Python and Rust. Are there other tools/programming languages that produce different output? Why not align with them?

The proposal makes the "normal" control flow that previously was easy to detect by looking at return statements now hidden. Any assignment to a variable that is under "watch" can now exit the function.

var buf [4]byte
slice := buf[:]
watch buf, slice {
   ...
}
...
copy(buf[:], foo) // triggers watch?
copy(slice, foo) // triggers watch potentially exiting the function
...

There also a bunch of open question about behaviour that would need to be clarified:

• what if a pointer to a variable is passed into another function. Is changing the value of the variable then triggering the watch even while in the other functions?
• does another watch trigger when a value is assigned to a variable that is watched inside the watch itself?
• can multiple watches be defined in a function?
• can multiple watches be defined on the same variable?
• are variable assignment in defers still watched? what defers are still executed if a watch triggers in defer?
• what happens if a function closure is returned containing an assignment to a watched variable? Is the watch still active in the closure when returned or passed to a leave function, when called in the same function?
• for multiple assignments (f1, f2 = ....) and a watch on f1, f2. Is the watch triggered once or twice?

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version

</pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

What did you see instead?

There is nothing filled out in here to make this an actionable issue report.

If the goal is to reduce binary size then I dont think just splitting bytes is worth the churn in either Go 1 or Go 2.

Many other packages strings, fmt, reflect will still require unicode to be imported making the number of go programs after the split not importing Unicode very small still.

The ergonomics when programming of having to reason in which package to find the corresponding bytes function that previously were all together in one package is I think not worth the 22k byte saved.

To tackle this problem for all packages I think (apart from avoiding adding unicode dependencies were possible) is to work on compiler and linker optimisations making the imported parts of unicode smaller. e.g. https://github.com/golang/go/issues/38784 This also has the advantage of not requiring Go 2 incompatibilities.

Please specify the exact commands and sourcecode used to reproduce the error. From the issue filed its unclear where go test was run and with which code.

/cc @julieqiu

`package main

import ( "fmt" "runtime" "time" "unsafe" )

type ast struct { a int }

func (a *ast) free() { cnt++ fmt.Println("ast_free", unsafe.Pointer(a)) }

type bst struct { a *ast b **bst }

func (b *bst) free() { cnt++ fmt.Println("bst_free", unsafe.Pointer(b)) }

var cnt int

func testfreeCall2() { a := new(ast) b := new(bst) b.b = &b runtime.SetFinalizer(a, (*ast).free) runtime.SetFinalizer(b, (*bst).free)

b.a = new(ast)                         //Try to block this
runtime.SetFinalizer(b.a, (*ast).free) //Try to block this

fmt.Println("testfreeCall2__", unsafe.Pointer(a), unsafe.Pointer(b), unsafe.Pointer(b.a))

} func testfreeCall1() { a := new(ast) b := new(bst)

runtime.SetFinalizer(a, (*ast).free)
runtime.SetFinalizer(b, (*bst).free)
b.a = new(ast)
runtime.SetFinalizer(b.a, (*ast).free)

fmt.Println("testfreeCall1__", unsafe.Pointer(a), unsafe.Pointer(b), unsafe.Pointer(b.a))

}

func main() {

//testfreeCall1() //+3
testfreeCall2() //+1
//testfreeCall2() //+1
testfreeCall1() //+3

time.Sleep(1000 * 1000 * 100)
for i := 0; i < 5; i++ {
	runtime.GC()
	fmt.Println("status:", cnt, i)
	time.Sleep(1000 * 1000 * 100)
}

fmt.Println("exit")

} `

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

See https://github.com/golang/go/wiki/Questions for ressources to ask questions.

Mining

https://www.kernel.org/category/releases.html seems to suggest 3.18.11 is not supported anymore and quite old. So im not sure how effective it will be finding the bug and if it is on the linux side it may likely not get fixed. There may however be interest in learning what the issue is and if it could be reproduced on newer kernels (or reintroduced if not careful) if it isnt related to a known issue like: #35777

I think the next step is to figure out why async preemption interacts badly with the 3.18.11 kernel here.

For now you can programmatically disable asyncpreemption for now by setting GODEBUG=asyncpreemptoff=1 in your systems environment.

Relevant issue about homographs attacks: https://github.com/golang/go/issues/20115

I cant build minikube due to other reasons.

$ git clone https://github.com/kubernetes/minikube
$ cd minikube/cmd/minikube/
$ go build
# k8s.io/minikube/pkg/minikube/translate
../../pkg/minikube/translate/translate.go:80:12: undefined: Asset

how was the code in /Users/ouyangbin/Downloads/source_code/minikube-master/ obtained?

Wild guess could be https://github.com/golang/go/issues/35777 ? Try running with GODEBUG=asyncpreemptoff=1 and see if that avoids the crashes.

Making it a compiler error will be a hard stop to this. On the other side these code instances will lead to subtle memory corruption bugs that need the right circumstances come together and may not be caught by tests just checking for correct output values of the functioncs involved. They can be hard to diagnose which could justify this.

Unfixed example in the wild: https://github.com/alecthomas/unsafeslice/issues/4 Corresponding static check proposal: https://github.com/dominikh/go-tools/issues/782

Because the fact that it doesn't inline range loops, then if I call memset(s, 0) it will call to memset and then loop instead of just calling to runtime.memclrNoHeapPointers which it could've done if it new that c=0

I dont think the existing range clear optimizations will trigger even if the inlining is changed. Thats something that will not only need inlining but the range clear optimization to move after some ssa pass optimizations that propagate that c is a constant.

Best short term bet is to write it directly:

To me having all unary operators also on the left side impairs readability as the operation on both left and right side need now be merged mentally to understand how the value of an expression assigned is computed. They might also be visually much further away the current examples. * is special in that regard as it only signifies where to store a value unmodified.

The most feedback to keep support seems to come from users with AMD Geode GX/LX (the kind with MMX but not SSE or SSE2) boards still used in the embedded space/routers.

Im in favor of dropping 387. As an alternative go1.16 could be made to reinterpret GO386=387 to mean use softfloat support instead of 387 or SSE2 instructions. This would make ordinary go programs on 387 hardware still work, but slower. It would make the register based calling conventions still easier as other platforms (e.g. arm and mips) also require softfloat support. We would also have a mainstream platform for builders to test the softfloat code paths frequently. The upside is that e.g. Athlon XP and Pentium III keep on working and distros dont need to switch away from go gc to gogcc for their package builders for 386 distros supporting old hardware.

For verifying no newer instructionsets are used we could potentially use something like: https://software.intel.com/content/www/us/en/develop/articles/intel-software-development-emulator.html

https://github.com/ish-app/ish/issues/57 has been closed by ish-app supporting MOVQ now: https://github.com/ish-app/ish/commit/e898efeacf3f0f2b97fe2748d1fd86d0130f59de

Can this issue be closed?

The analyzer can tell you are passing function foo that can throw to function fmt.Printf that doesn't have catch to handle the throw.

The analyzer can not know that in all cases if e.g. foo being an interface{} value that came from somewhere populated at run time.

reflect can call normal functions just fine there is not constraint in the proposal or language that forbids functions called with reflect.Call to need to use reflect.Throw

I think it's the same as Go1's error. If you return an error as an interface, it will be hard to tell when a function will return an error or not.

True but there was no claim here that its possible to know where all error values are originating from either. Errors dominately are returned as error types directly which is possible to analyse statically and not as interface{}. This analysis also doesnt need whole program inter package analysis as knowing function signatures is enough. As there would be no explicit annotation for throws the analysis is quite a bit harder and has more commonly used language cases like function variables and reflect Calls where it will expensive or not knowable if a throw can happen.

It's very easy to recursively analyze the code to know if a throw is not caught by any catch.

This is not possible statically when reflect Call, function variables and plugins are involved without explicit anotation.

"is that existing builtin types that are iterable can automatically implement the iterator interface"

I think it needs to be spelled out what this means. How can []int implement the iterator interface? Does that mean []int would have a Next method which is a fairly invasive language change for all types now to have methods. Also next requires a state. How and when is this intialized/reset for a value like []int{1,2,3} ?

Would e.g. range use that iterator interface? Why not? If yes how?

Sure its already possible to use a copy. Not meaning to imply it was compelling. The compiler currently zeros key, then copies in strs with a typedslicecopy then moves the contents to a tmp and passes a pointer to the tmp copy to the runtime map routine. Ideally (which might be easier to optimize by the compiler) it would just pass a pointer to the backing array of the strs slice.

https://godbolt.org/

Anecdotal story for when I would like to have used this:

I was working on an optimization for a hot library code path. It was using a string as key to a map. That string got constructed by a strings.Join from a []string. For all practical purposes they were always 4 elements long. Due to historical reasons and generality the functions involved used a []string as input and changing this as it was a widely used API and config would have introduced alot of effort and churn in a large codebase.

Using [4]string as a map key (with a fallback for the case where it could have been used otherwise by joining the down to only using the first element of [4]string with a special terminal symbol) was a bit faster as it avoid an allocation to construct the string key. However there is no safe way to just convert []string to [4]string (or *[4]string) without copying [4]string (or allocating) which made the new code a bit slower then it needed to be.

Code that i liked to have ideally written for performance would have been (simplified):

if len(strs) == 4 {
   v := m[*(*[4]string)(strs)]
}

Googlers: Search for the phrase "In practice, entries always have four components" in the mono repo.

Furthermore, it is inconcevable that, for the default values, one could reach sum.golang.org, but not proxy.golang.org.

Im certain if given the access controls or due to the right set of circumstance to disable traffic to proxy.golang.org while sum.golang.org will be fine.

since they are the same service. They may or may not be currently. They dont have to be in the future and they dont have to use the same load balancer config.

Can you give a link to the russian tutorial that doesnt work?

There is still the possibility of the go proxy being unavailble while the sumdb is not. And the proxy might not have the module or be able to fetch the module while the sumdb already knows about it. Its nice to have a usable fallback to improve overall reliability.

Isnt there the possibility of companies running their own internal sum db with internal url set in GOSUMDB? This does not require that the external proxy has the same visibility to packages as the internal sum db server.

Test should be able to detect that there is a bad loop and time out. At which point the code causing the loop will be detected and can be fixed by the programmer.

If we put a limit on the depth it will be too low for some and to large (oom before reaching the limit) for others. An existing case similar to the problem is that fmt Stringer can get into an infinite recursion too.

See https://github.com/golang/go/issues/40432.

Especially: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md For why implicit checking/implicit results is not prefered for error handling.

large switch cases already impact readability to me with or without fallthrough. the new example is better dealt with in my mind with (function names to be adjusted to reflect actual use better):

switch t := v.(type) {
case pkg.One:
        processPkgOne(&t)
case *pkg.One:
        processPkgOne(t)
case pkg.Two:
        processPkgTwo(&t)
case *pkg.Two:
        processPkgTwo(t)        
case []byte:
        var d pkg.Data
        json.Unmarshal(t, &d)
        processPkgData(d)
case pkg.Data:
        processPkgData(t)
}

Same number of lines on the screen and I do not have to deal with the concept of fallthrough changing into the next block. Each block can be changed and removed without impacting any other block.

If the statements in each block are short and trivial (e.g. 1-3 lines) some lines can just be duplicated (as we save the fallthrough line) without taking up much more space. If the functionality is complex and common likely using a function makes sense for better testability. Has the added advantage that it can be used for any block in the switch case.

Another question would be why if *pkg.One and pkg.One behave the same can this is not be abstracted in an interface (which may also apply to pkg.Two) and all the cases together can be dealt with one interface conversion.

Is there any expression allowed after fallthrough as long as its assignable to the type of t in the next case block?