profile
viewpoint

google/go-cloud 7322

The Go Cloud Development Kit (Go CDK): A library and tools for open cloud development in Go.

google/wire 4420

Compile-time Dependency Injection for Go

google/codesearch 2423

Fast, indexed regexp search over large file trees

rsc/2fa 1127

Two-factor authentication on the command line

rsc/c2go 481

C to Go translation tool supporting Go toolchain migration

google/licensecheck 228

The licensecheck package classifies license files and heuristically determines how well they correspond to known open source licenses.

rsc/corpus 187

Corpus of interesting Go code

rsc/benchstat 122

Benchstat computes and compares statistics about benchmarks.

rsc/dbstore 45

Data structure interface to database/sql

rsc/binaryregexp 36

Go regexp for binary/latin-1 data

issue commentgolang/go

proposal: os: add ReadDir method for lightweight directory reading

Should Info be an optional method with an Info function that grabs the provided info or falls back to making a Stat?

I'm sorry, I didn't understand that, but it seems important to me that Info is a required method. Otherwise portable code that just wants to get some extra info is greatly complicated. That's a use case we do want to support well.

rsc

comment created time in 5 days

issue commentgolang/go

proposal: os: add ReadDir method for lightweight directory reading

Would old fses cache the Info like on Windows?

Yes. For clarity, there are four cases:

  1. Plan 9 and Windows return full metadata during directory read. On those systems, ReadDir would save that info. IsDir and Info would both use that saved info.

  2. Most Unix systems using most file systems return name, inode number, and inode type bits during directory read. On those systems, ReadDir would save that (more limited) info. IsDir would use the type bits to answer. Info would call Lstat each time it is called. If the Lstat fails, it returns an error. If the inode number or type bits don't match, it also returns an error (ErrNotExist probably).

  3. Old Unix systems (AIX, Solaris) return no type bits during directory read. On those systems, ReadDir would call Lstat for each directory entry and save that info, as Readdir does on all Unix systems. IsDir and Info would both use that saved info.

  4. Newer Unix systems can return no type bits (DT_UNKNOWN) during directory read for certain old file systems. On those systems, ReadDir would recognize DT_UNKNOWN and fall back to the "old Unix system" behavior.

Code using ReadDir and Info must be written so that it does not care whether the returned information is from the time of the ReadDir or the time of the Info call, in order to avoid optimizing for and overfitting to one operating system over another. A typical ReadDir+loop over entries inspecting them immediately fits this requirement - if there are racing changes to the underlying directory, it is already indeterminate whether the change would be observed or not, regardless of whether the observation is made during ReadDir or Info.

rsc

comment created time in 5 days

issue commentgolang/go

proposal: review meeting minutes

2020-09-23 / @rsc, @griesemer, @bradfitz, @ianlancetaylor, @andybons

  • #41385 all: add macOS ARM64 port
    • no change in consensus; accepted 🎉
  • #40995 all: add openbsd/mips64 port
    • no change in consensus; accepted 🎉
  • #40827 annotate which error values should never be wrapped
    • commented
  • #41337 cmd/cgo: get rid of CFType, JNI, EGL unsafe.Pointer => uintptr special cases
    • hold for GOPATH removal
  • #40276 cmd/go: 'go install' should install executables in module mode outside a module
    • discussion ongoing
  • #41145 cmd/go: allow -toolexec tools to opt in to build caching
    • proposal retracted by author; declined
  • #40870 cmd/go: build option to set env variable defaults
    • discussion ongoing
  • #37519 cmd/go: deprecate -insecure on go get
    • likely accept; last call for comments ⏳
  • #27628 cmd/go: do not cache tool output when using -toolexec
    • discussion ongoing
  • #40364 cmd/go: enable listing direct dependency updates
    • discussion ongoing
  • #40323 cmd/go: notify about newer major versions
    • put on hold
  • #41184 cmd/go: start conversion to bug-resistant //go:build constraints
    • no change in consensus; accepted 🎉
  • #40701 cmd/vet: warn about variables/values of type reflect.{Slice,String}Header
    • no change in consensus; accepted 🎉
  • #41066 crypto/tls: export/replace errClosed
    • no change in consensus; accepted 🎉
  • #40171 crypto: import fiat-crypto implementations
    • likely accept; last call for comments ⏳
  • #41196 doc: require auto-generated DO NOT EDIT comment at top of file
    • no change in consensus; accepted 🎉
  • #41191 embed, cmd/go: add support for embedded files
    • no change in consensus; accepted 🎉
  • #41198 errors: add ErrUnsupported
    • likely accept; last call for comments ⏳
  • #40138 flag: function to add long and short version of a flag
    • likely decline; last call for comments ⏳
  • #41190 io/fs: add file system interfaces
    • commented
  • #40962 io: add ReadSeekCloser interface
    • discussion ongoing
  • #39057 log: export log.std as log.Default
    • discussion ongoing
  • #41324 net/http/pprof: provide a mechanism to render on /debug/pprof profiles than those that invoke pprof.NewProfile
    • discussion ongoing
  • #41048 net/http: add Transport.GetProxyConnectHeader
    • likely accept; last call for comments ⏳
  • #41182 net/http: automatically set Content-Length from Len method on Body
    • discussion ongoing
  • #40860 os/exec: method Cmd.String print Env
    • discussion ongoing
  • #41467 os: add ReadDir method for lightweight directory reading
    • commented
  • #41265 os: fast, comprehensive directory API
    • likely decline; last call for comments ⏳
  • #41188 os: make Readdir return lazy FileInfo implementations
    • proposal retracted by author; declined
  • #40352 os: new Readdirentries method to read directory entries and efficiently expose file metadata
    • hold for #41467
  • #37113 path/filepath: add a function to canonicalize paths
    • commented
  • #40198 regexp: add Replace and ReplaceString
    • discussion ongoing
  • #40238 runtime: add mechanism to configure format used to write out unhandled panics
    • discussion ongoing
  • #41054 runtime: allow termination of blocked syscalls
    • no change in consensus; declined
  • #39214 testing: add CPU name to standard benchmark labels
    • likely accept; last call for comments ⏳
  • #41260 testing: add TB.Setenv()
    • discussion ongoing
  • #40984 testing: middleware for testing.TB (?)
    • discussion ongoing
  • #39726 time: Duration should have .Ceil method
    • no change in consensus; declined
  • #41438 x/net: add xsrftoken.ValidFor
    • discussion ongoing
rsc

comment created time in 5 days

issue commentgolang/go

proposal: os: add ReadDir method for lightweight directory reading

@carlmjohnson Yes, one of the goals here is to establish an API for io/fs that enables a standard fast walk API, probably similar to github.com/kr/fs Walker, and close #16399.

rsc

comment created time in 5 days

issue commentgolang/go

proposal: flag: add SetHelpOutput to specify the destination for help explicitly

Note that SetHelpOutput would be inappropriate when --help is not specified, that is, when Usage is being called because of an unknown command-line flag. Even the GNU tools print to standard error in that case.

I would suggest that if you really want to implement -help, add that as a flag using the new flag.Func, and then it's easy to do:

os.Stderr = os.Stdout

at the top of your implementation.

Songmu

comment created time in 5 days

issue commentgolang/go

proposal: sort: add the Dedup function

I'm not convinced this should be tied up with sorting at all. Yes, if you sort first then you can remove more duplicates. But the removing duplicates operation can make sense even on unsorted data (without a sort step).

I expected that this would be slices.Uniq once generics happen.

rokkerruslan

comment created time in 5 days

issue commentgolang/go

proposal: reflect: add StructField.IsExported

I'm OK with adding IsExported() bool. I wouldn't want to add a new struct field that could be out of sync with PkgPath.

dsnet

comment created time in 5 days

issue commentgolang/go

proposal: annotate which error values should never be wrapped

I think it's just io.EOF. Are there others?

dpifke

comment created time in 5 days

issue commentgolang/go

proposal: io: add ReadSeekCloser interface

I started looking at this and it does get a defined a lot. Will report back with stats but it might be worth doing.

mohamedattahri

comment created time in 5 days

issue commentgolang/go

proposal: path/filepath: add a function to canonicalize paths

If you change EvalSymlinks to call GetFinalPathNameByHandle on Windows, it may break some apps, so I'm pretty sure Alex wouldn't agree.

It would need to keep doing what it's documented to do, namely preserve relative-ness to current directory when possible. That means calling GetFinalPathNameByHandle and fixing up the result a little. But we could still build a function around GetFinalPathNameByHandle that should handle everything Windows can throw at it.

Did you have a specific breakage in mind?

bk2204

comment created time in 5 days

issue commentgolang/go

proposal: crypto: import fiat-crypto implementations

Based on the discussion above, this seems like a likely accept.

mdempsky

comment created time in 5 days

issue commentgolang/go

proposal: crypto: import fiat-crypto implementations

BSD-1-Clause will be fine, thanks.

mdempsky

comment created time in 5 days

issue commentgolang/go

proposal: cmd/go: deprecate -insecure on go get

Based on the discussion above this seems like a likely accept. (I see the code has already landed but might as well finish the process.)

witchard

comment created time in 5 days

issue commentgolang/go

proposal: io/fs: add file system interfaces

Waiting on #41467, which seems to be converging.

rsc

comment created time in 5 days

issue commentgolang/go

proposal: errors: add ErrUnsupported

Based on the discussion above, the proposal detailed in https://github.com/golang/go/issues/41198#issuecomment-694577588 seems like a likely accept.

ianlancetaylor

comment created time in 5 days

issue commentgolang/go

proposal: errors: add ErrUnsupported

@darkfeline, it's always going to be fine to define your own if you don't want to use the common one. But that probably shouldn't preclude having a common one.

ianlancetaylor

comment created time in 5 days

issue commentgolang/go

proposal: os: add ReadDir method for lightweight directory reading

We're not putting flags into the argument to ReadDir. That's too much API complexity.

Let's call the systems that don't return IsDir bits in the readdir system call "old". For concreteness, those systems are AIX, Solaris, and certain old file systems on other systems (unclear which, but not very many).

It seems like the options are:

  1. Make IsDir lazy on old systems but return false if it runs into a problem. This is a lie.
  2. Make IsDir lazy on old systems but returning (bool, error) (all systems). Then it ends up different from FileInfo and complicates call sites.
  3. Make ReadDir prefetch the IsDir results on old systems. This is a little slower (like Readdir today) but doesn't affect most systems, avoids an API difference with FileInfo, and avoids the need to worry about synchronization between lazy IsDir and lazy Info.

Given how rare the problem seems to be, it seems like we should probably take option (3), keeping these old systems from causing API complexity on all the others.

rsc

comment created time in 5 days

issue closedgolang/go

proposal: os: make Readdir return lazy FileInfo implementations

An os.File provides two ways to read a directory: Readdirnames returns a list of the names of the directory entries, and Readdir returns the names along with stat information.

On Plan 9 and Windows, Readdir can be implemented with only a directory read - the directory read operation provides the full stat information.

But many Go users use Unix systems.

On most Unix systems, the directory read does not provide full stat information. So the implementation of Readdir reads the names from the directory and then calls Lstat for each file. This is fairly expensive.

Much of the time, such as in the implementation of filepath.Glob and other file system walking, the only information the caller of Readdir really needs is the name and whether the name denotes a directory. On most Unix systems, that single bit of information—is this name a directory?—is available from the plain directory read, without an additional stat. If the caller is only using that bit, the extra Lstat calls are unnecessary and slow. (Goimports, for example, has its own directory walker to avoid this cost.)

Various people have proposed adding a third directory reading option of one form or another, to get names and IsDir bits. This would certainly address the slow directory walk issue on Unix systems, but it seems like overfitting to Unix.

Note that os.FileInfo is an interface. What if we make Readdir return a slice of lazily-filled os.FileInfo? That is, on Unix, Readdir would stop calling Lstat. Each returned FileInfo would already know the answer for its Name and IsDir methods. The first call to any of the other methods would incur an Lstat at that moment to find out the rest of the information. A directory walk that uses Readdir and then only calls Name and IsDir would have all its Lstat calls optimized away with no code changes in the caller.

The downside of this is that the laziness would be visible when you do the Readdir and wait a while before looking at the results. For example if you did Readdir, then touched one of the files in the list, then called the ModTime method on the os.FileInfo that Readdir retruned, you'd see the updated modification time. And then if you touched the file again and called ModTime again, you wouldn't see the further-updated modification time. That could be confusing. But I expect that the vast majority of uses of Readdir use the results immediately or at least before making changes to files listed in the results. I suspect the vast majority of users would not notice this change.

I propose we make this change—make Readdir return lazy os.FileInfo—soon, intending it to land in Go 1.16, but ready to roll back the change if the remainder of the Go 1.16 dev cycle or beta/rc testing turns up important problems with it.

/cc @robpike @bradfitz @ianthehat @kr

closed time in 5 days

rsc

issue commentgolang/go

proposal: os: make Readdir return lazy FileInfo implementations

Retracting per discussion above; see #41467.

rsc

comment created time in 5 days

issue commentgolang/go

proposal: net/http: add Transport.GetProxyConnectHeader

Based on the discussion above, this seems like a likely accept.

bradfitz

comment created time in 5 days

issue commentgolang/go

proposal: cmd/go: allow -toolexec tools to opt in to build caching

Unfortunately, via plain go build I don't have a good way to obtain myexec's own version.

I don't understand this. Every program gets a build ID, right? It seems like you should be able to fetch the build ID from os.Executable instead of doing the full sha256 of the executable.

mvdan

comment created time in 5 days

issue commentgolang/go

proposal: cmd/go: do not cache tool output when using -toolexec

I still think -toolexec should be completely orthogonal from the cache. There are times when you want to force a tool to run (as an extreme case, -a), and we can and should handle those independently of whether -toolexec is being used.

cherrymui

comment created time in 5 days

issue commentgolang/go

proposal: testing: add CPU name to standard benchmark labels

It sounds like between the commands and auxv we have getting the info covered. No one is arguing against this, so it seems like a likely accept.

martisch

comment created time in 5 days

issue commentgolang/go

proposal: cmd/cgo: get rid of CFType, JNI, EGL unsafe.Pointer => uintptr special cases

It sounds like in the long term it would be good to clean up, but we need to wait for GOPATH to be gone so that all Go code is versioned at least at the top module (and then we'll define the implicit Go version for module dependencies without go.mod, but we can't do that yet). Putting on hold for now.

eliasnaur

comment created time in 5 days

issue commentgolang/go

proposal: net/http/pprof: provide a mechanism to render on /debug/pprof profiles than those that invoke pprof.NewProfile

It still seems a bit odd that this is for registering non-pprof profiles.

Above I suggested:

Maybe instead the /debug page (which I think does nothing now) should list the available pages under /debug? Then when fgprof registers /debug/fgprof, it gets listed in /debug automatically?

Any reaction to that? It seems clearer not to put it in the /debug/pprof list or URL.

brancz

comment created time in 5 days

issue commentgolang/go

proposal: os: fast, comprehensive directory API

Based on the discussion above, this seems like a likely decline.

networkimprov

comment created time in 5 days

issue commentgolang/go

proposal: testing: add TB.Setenv()

Summarizing the discussion, it seems like the arguments in favor are that:

  • Programs do sometimes need to test behavior in response to environment variables.
  • Undoing the Setenv is a little tricky (Unsetenv vs Setenv to old value).
  • A helper on testing.T can also verify that there are no parallel tests running.

The argument against seems to be:

  • Tested code shouldn't change behavior based on environment variables.
  • Providing the feature may encourage people to use environment variables more.

On balance it seems like the arguments in favor outweigh the ones against. Do I have that right?

sagikazarmark

comment created time in 5 days

issue commentgolang/go

proposal: flag: function to add long and short version of a flag

Based on the discussion above (in particular it being a duplicate of #35761 and half-impossible), this seems like a likely decline.

lolbinarycat

comment created time in 5 days

issue commentgolang/go

proposal: os: new Readdirentries method to read directory entries and efficiently expose file metadata

If #41467 is accepted, I think we can close this one.

israel-lugo

comment created time in 5 days

issue commentgolang/go

proposal: runtime: add mechanism to configure format used to write out unhandled panics

Adding to minutes, but the discussion seems to be trending toward decline.

mitar

comment created time in 5 days

issue commentgolang/go

proposal: regexp: add Replace and ReplaceString

Adding to the proposal minutes for visibility. We'd need to see more need beyond what is already there.

kpym

comment created time in 5 days

issue commentgolang/go

proposal: net/http: automatically set Content-Length from Len method on Body

Adding to the proposal minutes. Len() int still seems like not enough signal for me.

jingyugao

comment created time in 5 days

issue commentgolang/go

proposal: log: export log.std as log.Default

To restate, the proposal here is to add

package log

// Default return the default Logger used by top-level function like Print, SetOutput, and so on.
func Default() *Logger

I don't see much enthusiasm for this in the comments and reactions above, but let's put it in the minutes and see if more people chime in.

carnott-snap

comment created time in 5 days

issue commentgolang/go

proposal: doc: require auto-generated DO NOT EDIT comment at top of file

No change in consensus, so accepted

rsc

comment created time in 5 days

issue commentgolang/go

proposal: cmd/go: start conversion to bug-resistant //go:build constraints

Please note that accepting this means that //go:build lines will start working in Go 1.17, not Go 1.16. Don't everyone rush to put them in.

rsc

comment created time in 5 days

issue commentgolang/go

proposal: cmd/go: start conversion to bug-resistant //go:build constraints

No change in consensus, so accepted.

rsc

comment created time in 5 days

issue commentgolang/go

proposal: all: add macOS ARM64 port

No change in consensus, so accepted.

cherrymui

comment created time in 5 days

issue commentgolang/go

proposal: all: add openbsd/mips64 port

No change in consensus, so accepted.

4a6f656c

comment created time in 5 days

issue commentgolang/go

proposal: cmd/vet: warn about variables/values of type reflect.{Slice,String}Header

No change in consensus, so accepted.

mdempsky

comment created time in 5 days

issue commentgolang/go

proposal: crypto/tls: export/replace errClosed

No change in consensus, so accepted.

ainar-g

comment created time in 5 days

issue commentgolang/go

proposal: embed, cmd/go: add support for embedded files

No change in consensus, so accepted.

rsc

comment created time in 5 days

issue closedgolang/go

proposal: time: Duration should have .Ceil method

<!-- 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 go1.14.4 </pre>

Does this issue reproduce with the latest release?

Yes

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="" GOCACHE="/home/jaap/.cache/go-build" GOENV="/home/jaap/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/jaap/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/lib/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" 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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build626039516=/tmp/go-build -gno-record-gcc-switches" </pre></details>

Having a ceil method is usefull for cases where you have a minimum duration, but in reality it needs to be on a per X basis, so the duration might only be 0.5 seconds, but in-reality it can only finish once aa second so you want to round it up to 1 second. The Time package provides a time round method for rounding to the nearest X and a truncate method for rounding down(towards 0) but not the other way around (away from 0) making it incomplete.

closed time in 5 days

JAicewizard

issue commentgolang/go

proposal: time: Duration should have .Ceil method

No change in consensus, so declined.

JAicewizard

comment created time in 5 days

issue closedgolang/go

proposal: runtime: allow termination of blocked syscalls

Many syscalls may block indefinitely, for example file ops trying paths on a network filesystem or peripheral device that's unavailable. Such syscalls can often be terminated, but Go is unable to do so at present. So today, Go apps...

  • can't retry a dir, file, etc while it's unavailable without leaking an OS thread on every attempt.
  • can't let you abandon a stalled task.
  • may return immediately to a stalled state after abort and restart.

CIFS (#39237, #38836) and FUSE (#40846) support this by returning EINTR instead of restarting after a signal. NFS on Linux used to do the same, but dropped it a while ago. So not all hung syscalls can be terminated gracefully.

Rust used to retry syscalls on EINTR, but dropped the practice outside of some high-level APIs.

The runtime should provide a way to terminate blocked syscalls. On unix, this entails sending the blocked thread a signal. Windows has an analogous mechanism, CancelSynchronousIo(). See also https://docs.microsoft.com/en-us/windows/win32/fileio/canceling-pending-i-o-operations.

The solution must not add context.Context variants of all stdlib APIs that make blocking syscalls. Mandating Context arguments for termination would force them into third party package APIs, and code importing those packages would then be broken. If a package author did not amend its API, the callers would have to manage stalled ops some other way, and likely leak resources on every op retry.

I think the simplest way to allow this (other ideas welcome) is to asynchronously post a threadId & metadata to the app (edit: or an internal table) immediately before and after trying a blocking syscall.

The following API could be introduced as experimental (edit: or internal). If we also want cancellable variants of stdlib APIs, Add/DropSyscallPost() could take an argument limiting its scope to the current goroutine, for use by the variants.

A file-oriented variation of this appears in https://github.com/golang/go/issues/41054#issuecomment-692267226. A runtime-internal variation is suggested in https://github.com/golang/go/issues/41054#issuecomment-683155474.

package runtime

// A callback typically implemented to maintain a table of ThreadIds and syscall metadata.
// The name is OS-specific; if "-", thread has completed its syscall.
type PostSyscall func(thread ThreadId, name string, args ...interface{})

// Notify the app of blocking syscalls, by invoking post asynchronously. Each function added is invoked.
// An error results if post is already known.
func AddSyscallPost(post PostSyscall) error

// Stop notifications via post.
// An error results if post is unknown.
func DropSyscallPost(post PostSyscall) error

// Try to terminate a syscall blocked in thread.
// An error results if thread is invalid.
func TerminateSyscall(thread ThreadId) error

// The error returned by syscall after termination.
// The caller should retry the syscall if TerminateSyscall() wasn't called for this thread.
type InterruptError struct { thread ThreadId }

Discussion of this began (more or less) with https://github.com/golang/go/issues/40846#issuecomment-676777624

Changelog

27-Aug: add InterruptError and improve PostSyscall docs

closed time in 5 days

networkimprov

issue commentgolang/go

proposal: runtime: allow termination of blocked syscalls

No change in consensus, so declined.

networkimprov

comment created time in 5 days

issue commentgolang/go

net/http/pprof: imports html/template which causes larger binaries

Sure, go ahead.

egonelbre

comment created time in 5 days

issue commentgolang/go

proposal: os: add ReadDir method for lightweight directory reading

Neither AIX nor Solaris record the type of the file in the directory entry.

Thanks for pointing this out. That's unfortunate but good to know.

rsc

comment created time in 7 days

issue commentgolang/go

proposal: os: add ReadDir method for lightweight directory reading

It will cause confusion and bugs if .Info() & .IsDir() return new data every time on some filesystems but cached data on others.

Sorry, but that's the design constraint here: it must be possible to either return info learned during ReadDir or info learned during Info. Otherwise you are overfitting to either Unix or non-Unix and penalizing the other.

rsc

comment created time in 7 days

issue commentgolang/go

proposal: path/filepath: add a function to canonicalize paths

@networkimprov, the path length bugs are left alone only for lack of time. I don't think there's any objection to fixing them as long as it is done correctly and well.

@bk2204, I'm certainly not arguing against this functionality. I'm trying to understand why EvalSymlinks shouldn't be what provides this functionality on Windows.

(I do somewhat object to the name "canonical": if "/home/rsc" symlinks to some device path like "/u123/g3tah0uojq1/rsc", I have a hard time calling the latter the "canonical" one. And for what it's worth there are plenty of people who disagree with you about what "determine definitively if a path is under a directory" should mean. I have the bug reports to prove it. :-) But again, I'm not saying we shouldn't do this. I just think EvalSymlinks is probably the answer.)

bk2204

comment created time in 10 days

issue commentgolang/go

cmd/link: unexpected fault address (when low on disk space?)

I don't see any dissents on #41155 and it's marked NeedsFix already, so I won't comment there, but replying to the "if we do #41155" above:

I added SetPanicOnFault for exactly this specific use case, during an earlier, aborted rewrite of the linker. If an mmap fault is producing SIGBUS then that signal should be included, no question.

bradfitz

comment created time in 10 days

issue commentgolang/go

cmd/go: -cover stdout format is not consistent between failed & pass

Maybe, but "how long did it run before it failed?" is a more meaningful question than "what level of code coverage did it achieve before it failed?"

This discussion kind of trailed off, but I think the rough consensus here is that the output should be left as is.

christophermancini

comment created time in 10 days

issue commentgolang/go

cmd/go: override semantics break e.g. GOFLAGS=-ldflags

This discussion never fully resolved, but it sounds like the rough consensus is that the current behavior is working as intended.

stapelberg

comment created time in 10 days

issue commentgolang/go

proposal: crypto: import fiat-crypto implementations

Thanks very much.

mdempsky

comment created time in 10 days

issue commentgolang/go

proposal: cmd/go: notify about newer major versions

@adg, sure thing, moved to Hold. Please move back to the Active project column when you're ready.

zachgersh

comment created time in 10 days

issue commentgolang/go

proposal: cmd/go: build option to set env variable defaults

It's just more API surface that we are stuck with forever, and it's API surface that shouldn't even exist.

networkimprov

comment created time in 10 days

issue commentgolang/go

proposal: cmd/go: allow -toolexec tools to opt in to build caching

For the record (because I wasn't sure above), go build -toolexec=myexec already runs myexec compile -V=full:

% go build -toolexec=echo helloworld.go
go tool compile -V=full: unexpected output:
	/Users/rsc/go/pkg/tool/darwin_amd64/compile -V=full
go tool compile -V=full: unexpected output:
	/Users/rsc/go/pkg/tool/darwin_amd64/compile -V=full
go tool compile -V=full: unexpected output:
	/Users/rsc/go/pkg/tool/darwin_amd64/compile -V=full
mvdan

comment created time in 10 days

issue commentgolang/go

proposal: errors: add ErrUnimplemented as standard way for interface method to fail

@darkfeline, except ErrTemporary those errors are all defined in os and you are welcome to use them. Temporary turns out to be a very confusing concept in error handling and is beyond the scope of this issue.

ianlancetaylor

comment created time in 10 days

issue commentgolang/go

proposal: os: add ReadDir method for lightweight directory reading

I agree with what @diamondburned and @mpx said but just to reply directly as well.

This entails a per-item lstat() when the type is absent in native dirent. You don't want that if you don't need to check DirEntry.IsDir() for every result. Can it be optional?

In practice, when is that type absent? I'm not too worried if, say, VFAT file systems are slower to access.

Does DirEntry.Info() cache its result if it had to lstat(), or if ReadDir() had to?

The doc says the Info is either from the time of the ReadDir or the time of the Info call. So a stat during ReadDir can be cached, but not a stat during an earlier Info.

Could we flush the FileInfo cache, so a subsequent .Info() reloads it?

Adding cache state & manipulation to the API is needlessly complex. Lstat still exists.

Wouldn't the different behavior of DirEntry.Info() on unix & Windows cause trouble in cross-platform apps?

There is no magic wand here. Unix and Windows are different. They will always be different.

The path separator alone causes trouble in cross-platform apps. The answer is to use APIs like filepath.Clean and filepath.Join as appropriate. If you don't do that, you have trouble. It's not our job to make trouble impossible, only avoidable.

The docs on ReadDir are very clear about what you can rely on and what you cannot. If you rely on more than that, again, you will have trouble, same as hard-coding use of / or \ in your program.

Such apps would call os.File.Readdir() when they need FileInfo for all results, and xfs.File.ReadDir() otherwise. The mix of those two could be confusing.

Pretty much all apps should probably move to calling ReadDir or, if it matters, Lstat/Stat directly.

What's confusing is having two different APIs, but we clearly need a new one, and can't remove the old one. So be it.

There is no way to get the Windows fileId (analagous to inode) via FileInfo. Could a way be added to DirEntry? Unix dirents include the inode -- needed for tree replication. Could DirEntry provide that? For the latter two, I think you'd return a type FileId interface { ... }

[Note that Go would spell it FileID not FileId (the file does not have a mind).]

The concept seems too special-purpose for a general interface, and a bit difficult to use correctly. The problem is that Windows file IDs and Unix inode numbers are not really identifiers: they only identify a file within a particular file system. Another file system can have a file with the same file ID/inode number. So to use them properly you need to combine them with some kind of identifier for the file system itself (like fsid_t or dev_t on Unix). It gets messy fast.

Also, if you are writing "tree replication", then you are already stat'ing all the files to get the other metadata, and you're already writing very OS-specific code to preserve all the OS-specific attributes. That same code can easily grab the info you need as far as inode number and file system identifier.

It's not our job to union together all the possible APIs on all the possible systems. Our job is to find a simple API that is enough for the vast majority of Go programs, with an option for the rest to get at what they need (FileInfo.Sys in this case).

rsc

comment created time in 10 days

issue commentgolang/go

proposal: errors: add ErrUnimplemented as standard way for interface method to fail

If I implemented a database which does not support storing blobs bigger than 1 MB, would I return ErrUnsupported when attempting to store a 2MB blob?

Sure, if you want to.

If I implemented a wrapper around an audio device file (say, some specific external microphone device), would I return ErrUnsupported if the audio device file were missing?

Probably not. Sounds more like os.ErrNotExist.

In both cases, you need not use these. You are never required to use one, unless you are implementing an interface that requires it.

If it is meaningful for users to distinguish the specific "not supported" error, then instead of defining your own, you could use this one instead, same as os.ErrPermission, os.ErrNotExist, and so on. For example, see the http.Pusher interface doc. It defines specific conditions under which Push returns http.ErrNotSupported. If errors.ErrUnsupported existed, the Pusher interface could have used it.

ianlancetaylor

comment created time in 11 days

issue commentgolang/go

os: Symlink on Windows with a to-be-created directory path silently creates a link of the wrong type

We didn't quite resolve this above, but it looks like Ian and I both believe this is a documentation issue and that we shouldn't change anything now.

bcmills

comment created time in 11 days

issue commentgolang/go

proposal: flag: function to add long and short version of a flag

Sorry for the confusion, "this part" was supposed to be "part".

lolbinarycat

comment created time in 11 days

issue commentgolang/go

proposal: crypto: import fiat-crypto implementations

@JasonGross, thanks for replying. I certainly understand MIT not wanting to complete CLAs.

An alternative solution to our problem of imposing new notice requirements on every Go binary would be if the generator outputs could be licensed under a non-attribution license such as MIT-0 or a source-code-attribution-only license such as BSD-1-Clause.

Do you think that is a possibility?

mdempsky

comment created time in 11 days

issue commentgolang/go

proposal: os: add ReadDir method for lightweight directory reading

@benhoyt, added answers above but (1) I agree with you; (2) ReadEntries is the wrong long-term name, and in the long term Readdir will just be deprecated (but not removed) and fade away; (3) yes, Lstat; (4) yes, false.

rsc

comment created time in 11 days

issue commentgolang/go

proposal: cmd/go: build option to set env variable defaults

It sounds like the real problem is that there are two runtime bugs that have not been adequately addressed, and too many people are working around them by setting GODEBUG settings. The two workarounds that are being overused are madvdontneed=1, for various perceived or actual out-of-memory conditions on Linux; and asyncpreemptoff=1, for various problems with spurious EINTR returns from Linux.

For madvdontneed=1, I believe the state of the world is as @aclements summarized in https://github.com/golang/go/issues/33376#issuecomment-666455792. Go is doing the same thing as Java and Node here. It should not be necessary to set that. It is unfortunate that Linux tools like top/htop do not subtract out the lazyfree total from RSS in the display, but the OS knows what it can take away and will do that rather than OOM. That comment also says that container memory limits understand what Go is doing here too, so this should not be causing container OOMs either. If someone is seeing problems here, we need to get more information about their exact setup to help understand it better. Hence the (unanswered) questions to @elgatito above and more importantly on #37569. If there are other cases where using MADV_FREE is causing OOMs, please file details in a different issue and we will try to get to the bottom of that.

For asyncpreemptoff=1, the problem is that preemption has caused some (arguably buggy) kernel behavior returning EINTR where we weren't checking for it. And now I believe we are checking. If there are more places to check, let's fix those.

In both cases, fixing the specific bugs is more effective and will be easier than adding a new build option we will have to support for all time.

Let's fix the real bugs.

networkimprov

comment created time in 11 days

issue commentgolang/go

database/sql: SetConnMaxIdleTime without SetConnMaxLifetime has no effect

@jeremyfaller Should we close this?

jeremyfaller

comment created time in 11 days

issue commentgolang/go

x/crypto/ssh: DH SHA256 is extremely slow due to primality check

If dropping the primality check entirely is OK for the protocol, then that's fine.

If the check is kept, I'd rather see ProbablyPrime(1) than ProbablyPrime(0). The whole point of Miller-Rabin is the random base. BPSW's check hard-codes base 2, making it not really Miller-Rabin at all. For a random base instead of a fixed base, the chance of eluding detection with even a single round is very low, much lower than the 1/4 used in the standard proof, making the single round worth its cost as a backstop for BPSW alone. But again, if the entire check can be dropped, that's fine.

dacohen

comment created time in 11 days

issue commentgolang/go

proposal: cmd/go: allow -toolexec tools to opt in to build caching

@mdvan In that case it seems pretty clear that the tool that is altering the behavior of the compiler should be responsible for altering the -V=full output as well.

mvdan

comment created time in 11 days

issue commentgolang/go

proposal: cmd/go: build option to set env variable defaults

@networkimprov, lucky for us this build option wouldn't be backported either, so it isn't any better than a general fix to the EINTR problem. Let's solve that instead.

networkimprov

comment created time in 11 days

issue commentgolang/go

proposal: os: make Readdir return lazy FileInfo implementations

I certainly hear you all about the change being strange. I agree it's a bit odd. For what it's worth, I don't even think this is my idea. Brad says this has been proposed before.

The reason I'm trying hard to find a path forward here is that I'm trying to balance a few different concerns:

  • filepath.Walk can be made much faster by using the IsDir bits that are present in Unix directory reads without the full stat info. Tools like goimports substitute their own implementation doing just that. They get speed by giving up generality. That's fine since the case is actually specific anyway (it's always an OS file system underneath).
  • If the io/fs proposal (#41190) is adopted with no changes here, it will be impossible to achieve the same speed in a general Walk for FS. A few people raised that concern and it seems worth addressing.
  • Changes to the Walk API to help speed, such as something along the lines of https://pkg.go.dev/github.com/kr/fs#Walk, are worth considering but are impossible without a faster general underlying directory read.
  • If we're going to address that problem, now is the time.
  • We want to keep APIs simple (but as always not too simple).

Allowing lazy Readdir elegantly solves almost all of this, at the cost of the lazy behavior that seems from direct code inspection not to matter as much as you'd initially think. If we don't fix this problem now, we will be stuck with programs like goimports having their own custom filepath.Walk, and worse there will be no way to write a custom filepath.Walk for the general FS implementations.

If there's not consensus on the lazy Readdir - as there does not seem to be - then it still seems worth trying to fix the problem another way. Whatever we do, it needs to be a limited change: a simple, Go-like API. I expanded @mpx's suggestion above into a separate proposal, #41467. Please see the description and comment over there. Thanks.

rsc

comment created time in 11 days

issue openedgolang/go

proposal: os: add ReadDir method for lightweight directory reading

os.File provides two ways to read a directory: Readdirnames returns a list of the names of the directory entries, and Readdir returns the names along with stat information.

On Plan 9 and Windows, Readdir can be implemented with only a directory read - the directory read operation provides the full stat information.

But many Go users use Unix systems.

On most Unix systems, the directory read does not provide full stat information. So the implementation of Readdir reads the names from the directory and then calls Lstat for each file. This is fairly expensive.

Much of the time, such as in the implementation of file system walking, the only information the caller of Readdir really needs is the name and whether the name denotes a directory. On most Unix systems, that single bit of information—is this name a directory?—is available from the plain directory read, without an additional stat. If the caller is only using that bit, the extra Lstat calls are unnecessary and slow. (Goimports, for example, has its own directory walker to avoid this cost.) In fact, a survey of existing Go code found that only about 10% of uses of ReadDir actually need more than names and is-directory bits.

It appears that a third way to read directories should be added, to let all this code be written more efficiently. Expanding on a suggestion by @mpx, I propose to add:

// ReadDir reads the contents of the directory associated with the file f
// and returns a slice of DirEntry values in directory order.
// Subsequent calls on the same file will yield later DirEntry records in the directory.
//
// If n > 0, ReadDir returns at most n DirEntry records.
// In this case, if ReadDir returns an empty slice, it will return an error explaining why.
// At the end of a directory, the error is io.EOF.
//
// If n <= 0, ReadDir returns all the DirEntry records remaining in the directory.
// When it succeeds, it returns a nil error (not io.EOF).
func (f *File) ReadDir(n int) ([]DirEntry, error) 

// A DirEntry is an entry read from a directory (using the ReadDir method).
type DirEntry interface {
	// Name returns the name of the file (or subdirectory) described by the entry.
	// This name is only the final element of the path, not the entire path.
	// For example, Name would return "hello.go" not "/home/gopher/hello.go".
	Name() string
	
	// IsDir reports whether the entry describes a subdirectory.
	IsDir() bool
	
	// Info returns the FileInfo for the file or subdirectory described by the entry.
	// The returned FileInfo may be from the time of the original directory read
	// or from the time of the call to Info. If the file has been removed or renamed
	// since the directory read, Info may return an error satisfying errors.Is(err, ErrNotExist).
	Info() (FileInfo, error)
}

The FS proposal would then adopt this ReadDir and ignore Readdir entirely.

In #41188 I wrote:

Various people have proposed adding a third directory reading option of one form or another, to get names and IsDir bits. This would certainly address the slow directory walk issue on Unix systems, but it seems like overfitting to Unix.

I still believe that, but the survey convinced me that nearly all existing Readdir uses fall into this category, so it's not quite so bad to provide an optimized path for Unix systems. The DirEntry.Info method specification above allows both the eager info loading of Plan 9/Windows and the lazy loading needed on Unix. In contrast to #41188, the laziness is explicitly allowed from the beginning, and failures of the lazy loading can be reported in the error result.

Thoughts?

created time in 11 days

issue commentgolang/go

proposal: os: fast, comprehensive directory API

Proposal-Hold is not for "gonna need eventually".

networkimprov

comment created time in 11 days

issue commentgolang/go

proposal: net/http/pprof: provide a mechanism to render on /debug/pprof profiles than those that invoke pprof.NewProfile

@brancz What is the exact API, with function signatures and doc comments, that you are proposing?

brancz

comment created time in 11 days

issue commentgolang/go

proposal: errors: add ErrUnimplemented as standard way for interface method to fail

Given all the rationale in my previous comment, I would be fine with adding:

package errors

// ErrUnsupported indicates that a request operation cannot be performed because it is unsupported.
// Functions and methods should not return this error but should instead return an error including appropriate
// context that satisfies errors.Is(err, errors.ErrUnsupported), either by directly wrapping ErrUnsupported
// or by implementing an Is method.
var ErrUnsupported = New("unsupported operation")

Is this what you had in mind?

ianlancetaylor

comment created time in 11 days

issue commentgolang/go

proposal: errors: add ErrUnimplemented as standard way for interface method to fail

For me this issue comes down to what the error would be used for. I think that's what Bryan was trying to get at yesterday by drawing a distinction between "not implemented" and "not supported".

To make this concrete, and since the original comment above mentioned WriteString, consider an io.Writer wrapper w wrapping an underlying io.Writer u. Suppose this proposal is adopted to produce the error ErrTBD. And suppose w.WriteString is implemented as follows:

func (w) WriteString(s string) (int, error) {
    if u, ok := w.u.(io.StringWriter); ok {
        return u.WriteString(s)
    }
    return 0, ErrTBD
}

Is that a valid implementation of WriteString? Is it a valid use of ErrTBD? As I understood "not implemented", the answer to both of these was "yes", hence my reply above making an analogy to EINTR. I think "yes" has serious problems.

Ian's most recent comment makes it sound like the answer is "no, ErrTBD is inappropriate in this case; the method should end with return w.Write([]byte(s))". In that case, I'm much more comfortable with the idea and simply agree with Bryan that "not supported" is a better name for the idea than "not implemented". Too many people will think "not implemented" is OK to use in the WriteString example above - the method is, after all, not implemented on w.u.

All that said, it is important that this error not be used as a singleton like io.EOF. An operation that fails should still follow the standard advice to include information about the requested operation in the returned error. Same way that code should never directly return os.ErrPermission.

ianlancetaylor

comment created time in 11 days

issue commentgolang/go

proposal: io/fs: add file system interfaces

@Cyberax

What are exactly the concerns that prevent Context from being just added explicitly as an argument for all methods? I haven't seen the explanation anywhere.

I believe I addressed that in https://github.com/golang/go/issues/41190#issuecomment-690819876.

rsc

comment created time in 11 days

issue commentgolang/go

SIGBUS error when running make (because disk space consumed)

This looks like a real bug. I believe the new linker is memory mapping the output, but given the trace it appears not be using runtime/debug.SetPanicOnFault and reporting handling memory faults from I/O errors gracefully.

/cc @cherrymui @thanm @jeremyfaller

2018denjasa

comment created time in 11 days

issue commentgolang/go

sizeof: new package with constants for Int, Uint, Uintptr, Int8, Float64, etc

FWIW, I worry about sizeof(x) overfitting to expectations from C. I spoke to Rob about this, since he suggested the package approach in the first place, and he pointed out that having a package means we can extend it in interesting ways in the future, including things like calculating the actual memory size of a linked data structure, or a map, or a slice, or some other thing entirely, none of which is possible if we instead put C's sizeof(x) into the Go spec.

robpike

comment created time in 11 days

issue commentgolang/go

proposal: path/filepath: add a function to canonicalize paths

@networkimprov, you make assertions without being specific about them. I am confused about three of the things you've said related to this issue.

  • You linked to #40180 which is making a general software engineering argument along the lines of "you should never actually replace all the symlinks, that's violating the abstractions that have been set up". I have some sympathy for that, but if it were true, it would apply not just to EvalSymlinks but also this issue as well. If so, then we should just close this very issue (#37113) as a terrible idea.

  • I see that you mentioned this issue in #40966, which is about some problems with path lengths in EvalSymlinks on Windows. We've had path length problems elsewhere on Windows. Path length issues are usually pretty straightforward to fix. Why would we want to gate a fix to #40966 on a larger design discussion on this issue?

  • Finally, you said, with no links at all, "This proposal should probably also deprecate EvalSymlinks, which is seriously broken on Windows." How is it broken? That comment would be a good place for an issue link.

Thanks.

bk2204

comment created time in 11 days

issue closedgoogle/licensecheck

Proprietary software licenses

Hello,

I would like to know what's the current status regarding proprietary licenses. Are you considering to detect them (random example: by detecting some specific headers in the license file)?

I am trying to understand how can I get my proprietary library to be properly handled by pkg.dev.go. The fallback to godoc.org seems no longer possible.

closed time in 12 days

Julio-Guerra

issue commentgoogle/licensecheck

Proprietary software licenses

Licensecheck does now recognize a few commonly-used proprietary licenses, to give better results for people trying to understand potential new dependencies.

The bigger problem with your package is that https://github.com/sqreen/go-agent/blob/v0.15.0/LICENSE is not a license at all. A license needs to explicitly grant permission to do the things normally barred for copyrighted work, in exchange for following certain conditions. Your LICENSE file does none of that. It's also quite confusing, since "free to use" and "proprietary" are typically opposites.

As Jonathan said, the way to make your package appear in pkg.go.dev is to adopt a license that properly captures and states the conditions under which others can use it. If those conditions permit us to show it on pkg.go.dev (right now, that means it is a license the list Jonathan linked) then we will.

Julio-Guerra

comment created time in 12 days

issue commentgolang/go

proposal: review meeting minutes

2020-09-16 / @rsc, @griesemer, @bradfitz, @ianlancetaylor, @andybons, @spf13

  • #41385 all: add macOS ARM64 port
    • likely accept; last call for comments ⏳
  • #40995 all: add openbsd/mips64 port
    • likely accept; last call for comments ⏳
  • #41130 builtin: delete returns bool
    • proposal retracted by author; declined
  • #41337 cmd/cgo: get rid of CFType, JNI, EGL unsafe.Pointer => uintptr special cases
    • commented
  • #41145 cmd/go: allow -toolexec tools to opt in to build caching
    • commented
  • #37519 cmd/go: deprecate -insecure on go get
    • commented
  • #40323 cmd/go: notify about newer major versions
    • likely decline; last call for comments ⏳
  • #41184 cmd/go: start conversion to bug-resistant //go:build constraints
    • likely accept; last call for comments ⏳
  • #40701 cmd/vet: warn about variables/values of type reflect.{Slice,String}Header
    • likely accept; last call for comments ⏳
  • #32406 crypto/tls: add (*tls.Conn).HandshakeContext and add context to ClientHelloInfo, CertificateRequestInfo
    • commented
  • #41066 crypto/tls: export/replace errClosed
    • likely accept; last call for comments ⏳
  • #40171 crypto: import fiat-crypto implementations
    • commented
  • #40511 database/sql: ScannerContext, ValuerContext support
    • no change in consensus; declined
  • #41196 doc: require auto-generated DO NOT EDIT comment at top of file
    • likely accept; last call for comments ⏳
  • #41191 embed, cmd/go: add support for embedded files
    • likely accept; last call for comments ⏳
  • #41162 encoding/json: make encoders set Content-Type
    • proposal retracted by author; declined
  • #41190 io/fs: add file system interfaces
    • commented
  • #41324 net/http/pprof: provide a mechanism to render on /debug/pprof profiles than those that invoke pprof.NewProfile
    • commented
  • #41048 net/http: add Transport.GetProxyConnectHeader
    • commented
  • #41265 os: fast, comprehensive directory API
    • commented
  • #41265 os: fast, comprehensive directory API
    • commented
  • #41188 os: make Readdir return lazy FileInfo implementations
    • discussion ongoing
  • #41054 runtime: allow termination of blocked syscalls
    • likely decline; last call for comments ⏳
  • #39214 testing: add CPU name to standard benchmark labels
    • commented
  • #41260 testing: add TB.Setenv()
    • commented
  • #39726 time: Duration should have .Ceil method
    • likely decline; last call for comments ⏳
  • #19367 unsafe: add Slice(ptr *T, len anyIntegerType) []T
    • discussion ongoing
rsc

comment created time in 12 days

issue commentgolang/go

proposal: os: fast, comprehensive directory API

Every person and every project has limited bandwidth for making decisions well, especially given the large amounts of time it can take to evaluate an idea fully. Redesigning the os.File API is not on our priority list right now. I'm sorry if that priority conflicts with yours, but again we have limited time and need to focus on higher-impact things.

It is of course fine to build your own APIs in a third-party package, as always.

networkimprov

comment created time in 12 days

issue commentgolang/go

proposal: path/filepath: add a function to canonicalize paths

What does "canonical" mean, precisely?

bk2204

comment created time in 12 days

issue commentgolang/go

proposal: net/http/pprof: provide a mechanism to render on /debug/pprof profiles than those that invoke pprof.NewProfile

It sounds like the request is to be able to add arbitrary HTML (or at least linked text) to the /debug/pprof page? That's not something we've done before and it seems like it might easy to abuse.

Maybe instead the /debug page (which I think does nothing now) should list the available pages under /debug? Then when fgprof registers /debug/fgprof, it gets listed in /debug automatically?

brancz

comment created time in 12 days

issue commentgolang/go

proposal: cmd/cgo: get rid of CFType, JNI, EGL unsafe.Pointer => uintptr special cases

I guess if you put a 1.16 in your go.mod file, then anyone importing your package must be building with >= 1.16, so that works.

This is not strictly speaking true. Go 1.15 will still try to compile the code, it will just include "by the way the module says it wants Go 1.16" along with any compile error. Maybe that's enough.

We could also wait on this until GOPATH is gone (so everyone has go.mod).

eliasnaur

comment created time in 12 days

issue commentgolang/go

proposal: all: add macOS ARM64 port

Given that we already have macOS and we have arm64 (and also all the Macs in the world will be arm64 before long, so the alternative is dropping the macOS port entirely), this seems fine and can be fast-tracked. This seems like a likely accept.

cherrymui

comment created time in 12 days

issue commentgolang/go

proposal: all: add openbsd/mips64 port

Given that we already have openbsd and we have mips64, then assuming we can arrange a builder this seems fine and can be fast-tracked. This seems like a likely accept.

@4a6f656c It takes seconds to generate a builder key. If it took months, it meant we missed an email until being reminded; sorry about that. Please ping us sooner if that happens again.

4a6f656c

comment created time in 12 days

issue commentgolang/go

proposal: crypto/tls: add (*tls.Conn).HandshakeContext and add context to ClientHelloInfo, CertificateRequestInfo

@johanbrandhorst, I'm still a bit confused. What I see in your CL is code that is plumbing contexts down to the Handshake and other getters, but I don't see how what's there would help with what @FiloSottile said above:

Another common problem that would be nice to solve at the same time is propagating info from the callbacks to net/http handlers. Maybe exposing this context also from ConnectionState would work, as it's exposed as Request.TLS? Or should the net/http Request context be a child of the TLS one? (How would that work with Server.BaseContext and Server.ConnContext?)

Another reason to expose it on ConnectionState is that the new VerifyConnection callback gets a ConnectionState as input. All other callbacks should be covered by ClientHelloInfo and CertificateRequestInfo.

Can we get a full API proposal here on the issue, along with details of how it would interact with net/http?

I can't tell from the CL what you are proposing to answer this part. Can you explain here in a comment? Maybe the answer is "don't do that", but if so it would be good to understand why.

johanbrandhorst

comment created time in 12 days

issue commentgolang/go

proposal: cmd/go: notify about newer major versions

This has been a long discussion and it seems clear that there isn't a consensus. We have #40357 accepted, which addresses some of the same things, so it would make sense to do that first and see what's left.

Based on all that, it seems like this should be a likely decline.

zachgersh

comment created time in 12 days

issue commentgolang/go

proposal: cmd/vet: warn about variables/values of type reflect.{Slice,String}Header

It sounds like there is consensus here that adding a vet check is OK. It also sounds like there is no consensus about broader compiler changes.

Since the title of the issue is tracking the vet change, this (the vet change) seems like a likely accept.

mdempsky

comment created time in 12 days

issue commentgolang/go

proposal: time: Duration should have .Ceil method

Based on the discussion above, this seems like a likely decline. It would be fine to file a new proposal for RoundUp/RoundDown, mentioning this one, if compelling use cases can be found. (The use case here does not quite work.)

JAicewizard

comment created time in 12 days

issue commentgolang/go

proposal: crypto: import fiat-crypto implementations

Ping @JasonGross. We'd be happy to use this code but don't want to impose new notice requirements on every Go binary.

mdempsky

comment created time in 12 days

issue commentgolang/go

proposal: cmd/go: deprecate -insecure on go get

This was placed on hold until GOPATH supported GOINSECURE. Now it does. What do people think? Should we deprecate and then remove -insecure? Perhaps deprecate (make it work but print a warning) in Go 1.16 and remove in Go 1.17?

witchard

comment created time in 12 days

issue commentgolang/go

proposal: doc: require auto-generated DO NOT EDIT comment at top of file

Based on the discussion above, this seems like a likely accept.

rsc

comment created time in 12 days

issue commentgolang/go

proposal: io/fs: add file system interfaces

In the discussion above, I see the concerns about wrapping and context, both of which I've replied to above and seem to have gotten positive responses. Are there other concerns about moving this proposal forward?

(Again, remember that we're not going to redo the os.File interface as part of this. That's off the table.)

rsc

comment created time in 12 days

issue commentgo-hep/hep

all: convert to go:build directives

Please wait until Go 1.17 to add any //go:build directives. Go 1.16 is only setting up for Go 1.17. Go 1.17 is the real change.

sbinet

comment created time in 12 days

issue commentgolang/go

proposal: cmd/go: start conversion to bug-resistant //go:build constraints

Based on the emoji above and the lack of any objections (along with the overwhelmingly positive Reddit thread), this seems like a likely accept.

rsc

comment created time in 12 days

issue commentgolang/go

proposal: net/http: add Transport.GetProxyConnectHeader

The Get is a bit non-standard but it does follow our pattern of having GetFoo func() T override Foo T in a struct when we realize too late that Foo T might not be initializable from the start. (For example, Request.GetBody vs Request.Body.)

Does anyone object to this?

bradfitz

comment created time in 12 days

issue commentgolang/go

proposal: crypto/tls: export/replace errClosed

Based on the discussion above, this seems like a likely accept.

ainar-g

comment created time in 12 days

more