golang
Repos
55

The Go programming language

106254
14957

Events

issue comment
build: unrecognized failures on freebsd-riscv64-unmatched

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "freebsd-riscv64-unmatched" && pkg == "" && test == ""
go tool dist: unknown architecture: riscv


build failed: make script failed: exit status 1

watchflakes

Created at 9 minutes ago
issue comment
build: unrecognized failures on freebsd-riscv64-unmatched

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "freebsd-riscv64-unmatched" && pkg == "" && test == ""
go tool dist: unknown architecture: riscv


build failed: make script failed: exit status 1

watchflakes

Created at 40 minutes ago
Created at 50 minutes ago
issue comment
time: JSON marshaling/unmarshaling does not work reliably for zero Time value

I see at least four defensible behaviors:

  1. Keep the status quo.
  2. Report an error when using any timezone with sub-minute offsets
  3. Always serialize a time.Time where IsZero reports true as "0001-01-01T00:00:00Z" regardless of timezone
  4. Support an json:",omitzero" tag option that elides a field if the IsZero reports true (see #45669).

Of the options, I like 2 and 4 the most.

Created at 1 hour ago
started
Created at 1 hour ago
opened issue
tour: [REPLACE WITH SHORT DESCRIPTION]

Context: https://go.dev/tour/welcome/1

Change the title above to describe your issue and add your feedback here, including code if necessary

Created at 1 hour ago
issue comment
time: JSON marshaling/unmarshaling does not work reliably for zero Time value

Thanks. This is failing because we use RFC 3339 format to marshal and unmarshal times, and that format can't represent the unusual sub-minute timezones used for Asia/Shanghai before 1901. I don't think we can fix this in general, but it may be worth handling the zero time.Time value specially.

CC @dsnet

Created at 1 hour ago
issue comment
Severely broken linting with extension

Seems like the issue is occurring due to this extension itself, as I disabled all other extensions and this still occurs.

You can view the logs here.

Created at 1 hour ago
started
Created at 1 hour ago
issue comment
x/build: update C compiler on Windows builders to a currently-maintained version

So, what is the supported gcc version for building Go from source on windows?

Created at 2 hours ago
issue comment
all: test failures using proxy.golang.org

Found new dashboard test flakes for:

#!watchflakes
default <- `(Get|read) "https://?proxy.golang.org/`
zip/zip_test.go:30:2: golang.org/x/tools@v0.1.12: Get "https://proxy.golang.org/golang.org/x/tools/@v/v0.1.12.zip": Service Unavailable

watchflakes

Created at 2 hours ago
opened issue
affected/package: time

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

Does this issue reproduce with the latest release?

Yes

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

What did you do?

https://go.dev/play/p/Xsu1BBKI26i

package main

import (
	"fmt"
	"time"
)

func main() {

	loc, _ := time.LoadLocation("Asia/Shanghai")
	time.Local = loc
	tlocal := time.Time{}.Local()

        fmt.Println("----- After UnmarshalJSON -----")
	fmt.Println(tlocal)
	fmt.Println(tlocal.Zone())
	fmt.Println(tlocal.IsZero())

	mal, _ := tlocal.MarshalJSON()
	recv := time.Time{}
	recv.UnmarshalJSON(mal)

	fmt.Println("----- After UnmarshalJSON -----")
	fmt.Println(recv)
	fmt.Println(recv.Zone())
	fmt.Println(recv.IsZero())
}

What did you expect to see?

----- Before MarshalJSON ----- 0001-01-01 08:05:43 +0805 LMT LMT 29143 true ----- After UnmarshalJSON ----- 0001-01-01 08:05:43 +0805 +0805 29143 // should be 29143 true // IsZero() should return true

What did you see instead?

----- Before MarshalJSON ----- 0001-01-01 08:05:43 +0805 LMT LMT 29143 true ----- After UnmarshalJSON ----- 0001-01-01 08:05:43 +0805 +0805 29100 // lost 43 seconds false // then IsZero() == false

Created at 2 hours ago
started
Created at 2 hours ago
started
Created at 2 hours ago
started
Created at 3 hours ago
started
Created at 3 hours ago
Created at 3 hours ago
issue comment
build: unrecognized failures on freebsd-riscv64-unmatched

Found new dashboard test flakes for:

#!watchflakes
post <- builder == "freebsd-riscv64-unmatched" && pkg == "" && test == ""
go tool dist: unknown architecture: riscv


build failed: make script failed: exit status 1

watchflakes

Created at 3 hours ago
issue comment
net/http: Dial I/O Timeout even when request context is not canceled

any update?

Created at 3 hours ago
issue comment
'build output "...." already exists and is not an object file' error after interrupted compilation

The only workaround seems to be to delete the output file and try again.

Created at 3 hours ago
opened issue
'build output "...." already exists and is not an object file' error after interrupted compilation

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

Does this issue reproduce with the latest release?

Unknown.

What did you do?

Rough steps:

  1. Interrupt a build with ^C
  2. Make some changes that cause our build system to attempt to rebuild the binary (like git rebase)
  3. Run the build

What did you expect to see?

No error.

What did you see instead?

go build go.fuchsia.dev/fuchsia/tools/fidl/fidlmerge: build output "../../../../fidlmerge" already exists and is not an object file

Upon inspection, the file starts with 4KB of 0x00s, which definitely isn't an object file. But the block of the file at 0x1000 does match the contents of the file that's written by the compiler if I delete the "bad" file and re-run the build.

Created at 3 hours ago
started
Created at 4 hours ago
fork
Created at 4 hours ago
Created at 4 hours ago
started
Created at 4 hours ago
issue comment
cmd/compile: inconsistent error messages based on type constraints

I agree with @ianlancetaylor here. All these cases are slightly different and result in slightly different inference mechanisms, resulting to slightly different errors.

This is not to say that we cannot do better - improving inference and related error messages was simply not the highest priority so far.

With respect to "but there seems to be multiple ways to define generics, all of which are subtly different with unknown consequences" I respectfully disagree: there's exactly one way to define generic types and functions, by declaring type parameters and constraints. We allow - as syntactic sugar - the leaving away of the interface wrapper around constraint types, which is about the only variation permitted.

But there are different ways to invoke/instantiate a generic function: with or without type inference, and when using type inference, with partial type argument lists.

Leaving this open for now, as a reference for when we work on better type inference and/or error messages.

Created at 4 hours ago
issue comment
cmd/link: external linking is nondeterministic on linux-arm64-longtest builder

Yeah, that does work! Thanks, @ianlancetaylor ! I'll send a CL tomorrow.

Created at 4 hours ago
started
Created at 5 hours ago
issue comment
cmd/link: external linking is nondeterministic on linux-arm64-longtest builder

Yeah, the file is from hostobjCopy, and it is from that assembly file. I'll try adding the .file directive. Thanks!

Created at 5 hours ago