text:
WebRTCPeerConnection crashes when initialized with TURN Server

The following code initializes correctly (The server is both STUN/TURN):
peer.initialize({ 		"iceServers": [ { "urls": ["stun:159.203.29.246:3478"] } ] 	})
However, the following will produce a backtrace:
peer.initialize({ 		"iceServers": [ { "urls": ["turn:159.203.29.246:3478"],                                            "username": "dryw",                                            "credentials": "testing123"                    } ] 	})
The crash appears to happen both on windows and linux. Editor is a custom build with Faless/godot@abcb079 + godot master godotengine/godot@930d6d8:
`Running: C:\Users\dpaulic\Desktop\godot\godot\bin\godot_windows_3.2_alpha2_Dryw.exe --path C:/Users/dpaulic/Desktop/bomber-rtc --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 6612 --position 448,240
Godot Engine v3.2.alpha.custom_build.acf1523e0 - https://godotengine.org
OpenGL ES 3.0 Renderer: Intel(R) HD Graphics 630
Connected 1456400343
Peer connected 1
ERROR: PeerConnection could not be created
ERROR: peer_connection.get() == nullptr
ERROR: WebRTCMultiplayer::add_peer: Condition ' p_peer->get_connection_state() != WebRTCPeerConnection::STATE_NEW ' is true. returned: ERR_INVALID_PARAMETER
At: modules\webrtc\webrtc_multiplayer.cpp:242
CrashHandlerException: Program crashed
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[0] godot_nativescript_init
[1] godot_nativescript_init
[2] <couldn't map PC to fn name>
[3] NativeScriptInstance::scalar deleting destructor' [4] Object::~Object (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:1942) [5] WebRTCPeerConnectionGDNative::scalar deleting destructor'
[6] Ref::unref (c:\users\dpaulic\desktop\godot\godot\core\reference.h:279)
[7] Variant::clear (c:\users\dpaulic\desktop\godot\godot\core\variant.cpp:1165)
[8] Variant::call_ptr (c:\users\dpaulic\desktop\godot\godot\core\variant_call.cpp:1117)
[9] GDScriptFunction::call (c:\users\dpaulic\desktop\godot\godot\modules\gdscript\gdscript_function.cpp:1082)
[10] GDScriptInstance::call (c:\users\dpaulic\desktop\godot\godot\modules\gdscript\gdscript.cpp:1170)
[11] Object::call (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:900)
[12] Object::emit_signal (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:1218)
[13] Object::_emit_signal (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:1150)
[14] MethodBindVarArg::call (c:\users\dpaulic\desktop\godot\godot\core\method_bind.h:344)
[15] Object::call (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:921)
[16] Variant::call_ptr (c:\users\dpaulic\desktop\godot\godot\core\variant_call.cpp:1096)
[17] GDScriptFunction::call (c:\users\dpaulic\desktop\godot\godot\modules\gdscript\gdscript_function.cpp:1082)
[18] GDScriptInstance::call (c:\users\dpaulic\desktop\godot\godot\modules\gdscript\gdscript.cpp:1170)
[19] Object::call (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:900)
[20] Object::emit_signal (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:1218)
[21] Object::emit_signal (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:1275)
[22] WebSocketClient::_on_peer_packet (c:\users\dpaulic\desktop\godot\godot\modules\websocket\websocket_client.cpp:109)
[23] wslay_event_recv (c:\users\dpaulic\desktop\godot\godot\thirdparty\wslay\wslay_event.c:753)
[24] WSLPeer::poll (c:\users\dpaulic\desktop\godot\godot\modules\websocket\wsl_peer.cpp:231)
[25] WSLClient::poll (c:\users\dpaulic\desktop\godot\godot\modules\websocket\wsl_client.cpp:224)
[26] MethodBind0::call (c:\users\dpaulic\desktop\godot\godot\core\method_bind.gen.inc:150)
[27] Object::call (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:921)
[28] Variant::call_ptr (c:\users\dpaulic\desktop\godot\godot\core\variant_call.cpp:1096)
[29] GDScriptFunction::call (c:\users\dpaulic\desktop\godot\godot\modules\gdscript\gdscript_function.cpp:1082)
[30] GDScriptInstance::call_multilevel (c:\users\dpaulic\desktop\godot\godot\modules\gdscript\gdscript.cpp:1180)
[31] Node::_notification (c:\users\dpaulic\desktop\godot\godot\scene\main\node.cpp:60)
[32] Object::notification (c:\users\dpaulic\desktop\godot\godot\core\object.cpp:933)
[33] SceneTree::_notify_group_pause (c:\users\dpaulic\desktop\godot\godot\scene\main\scene_tree.cpp:969)
[34] SceneTree::idle (c:\users\dpaulic\desktop\godot\godot\scene\main\scene_tree.cpp:526)
[35] Main::iteration (c:\users\dpaulic\desktop\godot\godot\main\main.cpp:1976)
[36] OS_Windows::run (c:\users\dpaulic\desktop\godot\godot\platform\windows\os_windows.cpp:3015)
[37] widechar_main (c:\users\dpaulic\desktop\godot\godot\platform\windows\godot_windows.cpp:162)
[38] _main (c:\users\dpaulic\desktop\godot\godot\platform\windows\godot_windows.cpp:186)
[39] main (c:\users\dpaulic\desktop\godot\godot\platform\windows\godot_windows.cpp:196)
[40] __scrt_common_main_seh (d:\agent_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[41] BaseThreadInitThunk
-- END OF BACKTRACE --
ERROR: NetSocketPosix::_get_socket_error: Socket error: 10054
At: drivers\unix\net_socket_posix.cpp:202`
This was tested using the bomber-rtc demo project. Removing  "iceServers"  and exposing the inner dictionary causes the program to run but it appears TURN servers do not function.
If a TURN server is required for testing, I can arrange credentials for mine!

It appears this is just a documentation error!
{     "iceServers": [         {             "urls": [ "stun:stun.example.com:3478" ], # One or more STUN servers.         },         {             "urls": [ "turn:turn.example.com:3478" ], # One or more TURN servers.             "username": "a_username", # Optional username for the TURN server.             "credentials": "a_password", # Optional password for the TURN server.         }     ] }
https://docs.godotengine.org/en/latest/classes/class_webrtcpeerconnection.html
Where "credentials" should be "credential" according to WebRTCLibPeerConnection.cpp. I will submit a documentation update PR when I have a some time.

Thanks for spotting it, yes, the key should be credential not credentials.
Anyway, it still shouldn't crash... I'll investigate that...

authors: Faless dryw

repo: godotengine/webrtc-native


text:
Peerto peer code review april 18

I think you could fix the problem with desktop version adding:
display: none;
in the desktop media query.

Your project looks great. contratulations!
I kindly suggest to  use lower case in the names of the elements and the link in the href# to work properly.
Happy coding 😃

I'm agree with @baezluise .... I think that he's right. We tested this suggestions with success.
Congrats @godybuoy

source: gharchive/issue

authors: baezluise jicamargo jlcarrascof

repo: godybuoy/portfolioset

license: MIT

license_type: permissive

license_source: github-api


text:
Enhance README.md

Update readme.md with website UI, and add different tags as needed.

Hello,
I'm reaching out to you regarding optimizing the README file.
Is your feature request related to a problem? Please describe.
After reviewing the current README, there's significant room for improvement to make it more engaging, informative, and user-friendly.
Describe the solution you'd like
I'll ensure that the instructions for getting started are concise, easy to follow, and include commands for installing dependencies and running the development server. I'll provide clear guidance on customizing the project by editing files in the /src folder, empowering users to tailor the project to their needs effortlessly. I'll highlight the global search feature, powered by the FlexSearch library, emphasizing its accessibility and ease of use with a keyboard shortcut (⌘K) also include links to relevant documentation and resources for further learning about the technologies used in the project, such as Tailwind CSS, Next.js, and more.
I'm eager to take on this task and look forward to the opportunity to contribute to this project.
Please assign me this issue under GSSOC24

authors: SanjanaBankar aryanmehrotra

repo: gofr-dev/website


text:
https://itch.io/ platform support

This is yet another game platform (not to be mistaken for twitch)

It is already on the list of supported platforms:

authors: abendorg apaulouski

repo: gogcom/galaxy-integrations-python-api


text:
Set IsAdmin using LDAP

The IsAdmin flag is set based on whether the admin filter
returned any result. The admin filter is applied with the user dn
as the search root.
In the future, we should update IsAdmin as well on each login.
Alternately, we can have a periodic sync operation.

Thanks your PR!

In the future, we should update IsAdmin as well on each login.

It might not be ideal solution, because I think Gogs does not talk to LDAP server always, only when user session is expired, or preform operations that need password validation.

Looks all good.

source: gharchive/pull-request

authors: Unknwon gramakri

repo: gogits/gogs


text:
An empty ul + li pair in {{ .TableOfContents }}

What version of Hugo are you using (hugo version)?
hugo v0.115.3+extended
Does this issue reproduce with the latest release?
In hugo.yml
markup:
  goldmark:
    renderer:
      unsafe: true
      hardWraps: true
    tableOfContents:
      endLevel: 3
      ordered: true
      startLevel: 2

In markdown
## head 2
##### head 5
text

This will output an empty

 like this:

head 3

Duplicate of https://github.com/gohugoio/hugo/issues/7128

authors: MKPlato jmooring

repo: gohugoio/hugo


text:
.RenderShortcodes generates artifact when used nested in HTML

Configured renderer.unsafe=true and then using .RenderShortcodes in a shortcode used with % generates artifacts in the form of {{__hugo_ctx pid=3}}.
Is this intended?
This can be seen in the sample repo in http:/localhost:1313/posts
https://github.com/McShelby/hugo-testing/tree/hugo-issue-12854
What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.134.2-1c74abd26070b0c12849550c974a9f3f1e7afb06 windows/amd64 BuildDate=2024-09-10T10:46:33Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?
Yes. The used version was the latest.

Is this intended?

No, but I'm assuming you're doing something ... unusual that we didn't think of when we implemented this. Because it doesn't always happen.

Hm. I stripped the sample down to the bones. In my view, nothing special here.

This usage is unusual:
{{- range .Page.Pages }}

{{ .Title | safeHTML }}

{{ .RenderShortcodes | safeHTML }}

{{- end }}

I suggest you read the documentation and/or start a thread in the forum about the intention/use cases of .RenderShortcodes. It's a method with very limited but useful use: Including markdown in markdown, so to speak.

For others who may come around: The artifacts seem to be avoided if the shortcode is changed by adding a blank line in front of .RenderShortcodes.
{{- range .Page.Pages }}

{{ .Title | safeHTML }}

{{ .RenderShortcodes | safeHTML }}

{{- end }}

For others who may come around:
Please read and understand the documentation at https://gohugo.io/methods/page/rendershortcodes/ and consider if you really need to use this method. It is very useful, but it a special purpose method.
If you wrap your .RenderShortcodes in a div and pipe it to safeHTML, the answer is no.

Thanks bep for the fix.
Just for clarification, does this fix change your statement from above?

If you wrap your .RenderShortcodes in a div and pipe it to safeHTML, the answer is no.

Just for clarification, does this fix change your statement from above?

No.
The fix is to catch an error situation. I will print a warning (that can be turned off) about it.
The only use case I can think of for .RenderShortcodes is to include markdown blocks. Anything else just doesn't work.

Just for clarification, does this fix change your statement from above?

That said, the PR fixes 2 issues with similar symptoms (see test cases); one of them is perfectly valid use ...

@McShelby

adding a blank line

Regardless of  changes in #12996, you will still need a blank line, and that is expected per the CommonMark specification for HTML blocks. Specifically, read about the end condition for the sixth "type" of HTML block.

authors: McShelby bep jmooring


text:
server command panic when live add multihost

Stumbled into this while troubleshooting a user's config.
In HEAD, given the following config.toml:
baseurl = "/"

[Languages]
[Languages.en]
baseURL = "https://example.en"
languageName = "English"
weight = 1
title = "In English"
contentDir = "content"

# [Languages.de]
# baseURL = "https://example.de"
# languageName = "German"
# weight = 2
# title = "In German"
# contentDir = "content_de"

Run hugo server and then uncomment the de section.
panic: runtime error: index out of range

goroutine 107 [running]:
github.com/gohugoio/hugo/commands.server.func1(0xc4201340c0, 0xe63d86, 0xf)
        /home/X/src/github.com/gohugoio/hugo/commands/server.go:195 +0x712
github.com/gohugoio/hugo/commands.(*commandeer).loadConfig(0xc4201340c0, 0x14e5901, 0xc4201c1c78, 0x5a8d0a)
        /home/X/src/github.com/gohugoio/hugo/commands/commandeer.go:213 +0xc28
github.com/gohugoio/hugo/commands.(*commandeer).fullRebuild(0xc4201340c0)
        /home/X/src/github.com/gohugoio/hugo/commands/hugo.go:855 +0x34
github.com/gohugoio/hugo/commands.(*commandeer).newWatcher.func1(0xc42073e7a0, 0xc4201340c0, 0xc4207527b0, 0xc4207573d0)
        /home/X/src/github.com/gohugoio/hugo/commands/hugo.go:920 +0x48d
created by github.com/gohugoio/hugo/commands.(*commandeer).newWatcher
        /home/X/src/github.com/gohugoio/hugo/commands/hugo.go:896 +0x291

Offending line:  https://github.com/gohugoio/hugo/blob/e614d8a57c2ff5eef9270d51fcc6518398d7ff88/commands/server.go#L195

We should handle this more gracefully (and I suspect that my current work is maybe doing it), but we will not support adding and removing servers in the fly. So this config change will have to be followed by a restart.

I have the same problem when adding baseURL to the following config:
[Languages]
    [Languages.de]
        weight = 1
        LanguageName = "de"
        baseURL = "/"

    [Languages.en]
        weight = 2
        LanguageName = "en"
        baseURL = "/en/"

This index out of range error occurs:
Change of config file detected, rebuilding site.
2022-04-25 13:31:33.938 +0200
Rebuilt in 0 ms
panic: runtime error: index out of range [1] with length 1

goroutine 311 [running]:
github.com/gohugoio/hugo/commands.(*serverCmd).server.func1(0xc0002c80f0)
	github.com/gohugoio/hugo/commands/server.go:222 +0x6a5
github.com/gohugoio/hugo/commands.(*commandeer).loadConfig(0xc0002c80f0)
	github.com/gohugoio/hugo/commands/commandeer.go:360 +0x6b0
github.com/gohugoio/hugo/commands.(*commandeer).fullRebuild.func1()
	github.com/gohugoio/hugo/commands/hugo.go:802 +0x185
created by github.com/gohugoio/hugo/commands.(*commandeer).fullRebuild
	github.com/gohugoio/hugo/commands/hugo.go:787 +0x116

Unable to reproduce with v0.112.5.

We should handle this more gracefully ... but we will not support adding and removing servers in the fly. So this config change will have to be followed by a restart.

And that's exactly what happens.

authors: bep jmooring moorereason sr-verde


text:
Replace deprecated ioutil with io and os

This PR removes usages of io/ioutil.
The package io/ioutil is deprecated since Go 1.16:
Deprecated: As of Go 1.16, the same functionality is now provided by package io or package os, and those implementations should be preferred in new code. See the specific function documentation for details.

Changes

Replace ioutil.ReadAll, ioutil.Discard, ioutil.NopCloser with io.ReadAll, io.Discard, io.NopCloser.
Replace ioutil.ReadFile, ioutil.WriteFile, ioutil.ReadDir with os.ReadFile, os.WriteFile, os.ReadDir.
Replace ioutil.TempFile with os.CreateTemp.
Replace ioutil.TempDir with os.MkdirTemp.

Tests only

Replace ioutil.TempDir with t.TempDir(). T.TempDir automatically clears directory.
Refactor initFsTests by replacing ioutil.TempDir with t.TempDir and using t.Cleanup instead of manual cleanup.
Remove unused createEmptyTempDir and deleteTempDir after refactoring to t.TempDir.

Thanks for this. This needs to wait before I can merge; I have some bigger change sets in the merge pipeline in the near future, and I fear that these changes may create lots of potential merge conflicts.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: bep:x: alexandearYou have signed the CLA already but the status is still pending? Let us recheck it.

@alexandear I'm going to merge this once the tests go green, but a general remark for the future: If you have a PR that states that it does one isolated thing (ioutil => os) it would be good if it also doesn't do some refactoring of something totally unrelated. I know it's tempting and I'm certainly throwing stones in a glass house here, but it makes PRs like these much harder to reason about than they should.

authors: CLAassistant alexandear bep


text:
tpl: Modify 'Querify' to take lone slice argument

Querify used 'Dictionary' to add key/value pairs to a map to
build URL queries. Changed to dynamically generate ordered
key/value pairs. Cannot take string slice as key (earlier
possible due to Dictionary).
Fixes #6735

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Ujjwal Goyal seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Closing pull request as I had configured the incorrect commit email address.

authors: CLAassistant importhuman


text:
Fix incorrect BigQuery schema creation from FeatureSetSpec

BOOL value type in FeatureSetSpec is registered as repeated mode in BigQuery, because of incorrect comparison of the type Enum. It should be a single (non repeated) mode.
The comparison:
https://github.com/gojek/feast/blob/1ef1b712b56c00504f37fa4396ed1ebdce625f6a/ingestion/src/main/java/feast/ingestion/utils/StoreUtil.java#L121
The proto for the enum:
https://github.com/gojek/feast/blob/1ef1b712b56c00504f37fa4396ed1ebdce625f6a/protos/feast/types/Value.proto#L34
This pull request:

Add a test to ensure correct BigQuery schema is created.
Compare using the enum name suffix versus the enum int value. This makes the comparison more explicit.

/lgtm

authors: davidheryanto zhilingc

repo: gojek/feast


text:
Add PR template

Adapted from the kubernetes PR template.

/retest

Can we put a reference to an example release note if we are following the Kubernetes's ones?

I think it will be clearer for people if there is an example.

Can we put a reference to an example release note if we are following the Kubernetes's ones?

I think it will be clearer for people if there is an example.

done

/retest

/lgtm

authors: davidheryanto woop zhilingc


text:
Error while writing out vendor tree because of sirupsen/logrus

What version of Go (go version) and dep (git describe --tags) are you using?
go version
go version go1.8.3 darwin/amd64

 git describe --tags
v0.1.0-191-g4bfa359

What dep command did you run?
dep init -v

Full Log:
dep init -v
Root project is "github.com/Skarlso/miner"
 4 transitively valid internal packages
 8 external packages imported from 6 projects
(0)   ✓ select (root)
(1)	? attempt github.com/fsouza/go-dockerclient with 1 pkgs; 1 versions to try
(1)	    try github.com/fsouza/go-dockerclient@master
(1)	✓ select github.com/fsouza/go-dockerclient@master w/1 pkgs
(2)	? attempt github.com/hashicorp/go-cleanhttp with 1 pkgs; 1 versions to try
(2)	    try github.com/hashicorp/go-cleanhttp@master
(2)	✓ select github.com/hashicorp/go-cleanhttp@master w/1 pkgs
(3)	? attempt gopkg.in/yaml.v2 with 1 pkgs; 1 versions to try
(3)	    try gopkg.in/yaml.v2@v2
(3)	✓ select gopkg.in/yaml.v2@v2 w/1 pkgs
(4)	? attempt github.com/docker/go-units with 1 pkgs; 5 versions to try
(4)	    try github.com/docker/go-units@v0.3.1
(4)	✓ select github.com/docker/go-units@v0.3.1 w/1 pkgs
(5)	? attempt github.com/Yitsushi/go-commander with 1 pkgs; 4 versions to try
(5)	    try github.com/Yitsushi/go-commander@2.0.0
(5)	✓ select github.com/Yitsushi/go-commander@2.0.0 w/1 pkgs
(6)	? attempt github.com/kardianos/osext with 1 pkgs; 2 versions to try
(6)	    try github.com/kardianos/osext@master
(6)	✓ select github.com/kardianos/osext@master w/1 pkgs
(7)	? attempt github.com/docker/docker with 7 pkgs; 206 versions to try
(7)	    try github.com/docker/docker@v1.13.1
(7)	✓ select github.com/docker/docker@v1.13.1 w/25 pkgs
(8)	? attempt golang.org/x/sys with 1 pkgs; 1 versions to try
(8)	    try golang.org/x/sys@master
(8)	✓ select golang.org/x/sys@master w/1 pkgs
(9)	? attempt github.com/Azure/go-ansiterm with 2 pkgs; 2 versions to try
(9)	    try github.com/Azure/go-ansiterm@master
(9)	✓ select github.com/Azure/go-ansiterm@master w/2 pkgs
(10)  ? attempt github.com/fatih/color with 1 pkgs; 10 versions to try
(10)      try github.com/fatih/color@v1.5.0
(10)  ✓ select github.com/fatih/color@v1.5.0 w/1 pkgs
(11)  ? attempt github.com/docker/go-connections with 1 pkgs; 8 versions to try
(11)      try github.com/docker/go-connections@v0.2.1
(11)  ✓ select github.com/docker/go-connections@v0.2.1 w/1 pkgs
(12)  ? revisit github.com/docker/docker to add 3 pkgs
(12)    ✓ include 16 more pkgs from github.com/docker/docker@v1.13.1
(12)  ? revisit github.com/docker/go-connections to add 2 pkgs
(13)    ✓ include 2 more pkgs from github.com/docker/go-connections@v0.2.1
(12)  ? attempt golang.org/x/net with 1 pkgs; 4 versions to try
(14)      try golang.org/x/net@master
(14)  ✓ select golang.org/x/net@master w/1 pkgs
(13)  ? attempt github.com/opencontainers/runc with 2 pkgs; 19 versions to try
(15)      try github.com/opencontainers/runc@v0.1.1
(15)  ✓ select github.com/opencontainers/runc@v0.1.1 w/2 pkgs
(14)  ? attempt github.com/mattn/go-isatty with 1 pkgs; 4 versions to try
(16)      try github.com/mattn/go-isatty@v0.0.2
(16)  ✓ select github.com/mattn/go-isatty@v0.0.2 w/1 pkgs
(15)  ? revisit golang.org/x/sys to add 1 pkgs
(17)    ✓ include 1 more pkgs from golang.org/x/sys@master
(15)  ? attempt github.com/sirupsen/logrus with 1 pkgs; 42 versions to try
(18)      try github.com/sirupsen/logrus@v1.0.0
(18)  ✓ select github.com/sirupsen/logrus@v1.0.0 w/1 pkgs
(16)  ? revisit golang.org/x/net to add 2 pkgs
(19)    ✓ include 2 more pkgs from golang.org/x/net@master
(16)  ? attempt github.com/Microsoft/go-winio with 1 pkgs; 30 versions to try
(20)      try github.com/Microsoft/go-winio@v0.4.2
(20)  ✓ select github.com/Microsoft/go-winio@v0.4.2 w/1 pkgs
(17)  ? attempt github.com/pkg/errors with 1 pkgs; 11 versions to try
(21)      try github.com/pkg/errors@v0.8.0
(21)  ✓ select github.com/pkg/errors@v0.8.0 w/1 pkgs
(18)  ? attempt github.com/docker/distribution with 1 pkgs; 60 versions to try
(22)      try github.com/docker/distribution@v2.6.1
(22)  ✓ select github.com/docker/distribution@v2.6.1 w/2 pkgs
(19)  ? attempt github.com/mattn/go-colorable with 1 pkgs; 10 versions to try
(23)      try github.com/mattn/go-colorable@v0.0.8
(23)  ✓ select github.com/mattn/go-colorable@v0.0.8 w/1 pkgs
(20)  ? attempt github.com/Sirupsen/logrus with 1 pkgs; 42 versions to try
(24)      try github.com/Sirupsen/logrus@v1.0.0
(24)  ✓ select github.com/Sirupsen/logrus@v1.0.0 w/1 pkgs
  ✓ found solution with 58 packages from 20 projects

Solver wall times by segment:
     b-list-versions: 27.530092011s
         b-list-pkgs:  4.888328452s
              b-gmal:  4.345379635s
  b-deduce-proj-root:  444.165341ms
         select-atom:    40.34556ms
             satisfy:   30.271191ms
            new-atom:    5.598894ms
         select-root:    5.026212ms
               other:      82.817µs
     b-source-exists:      61.153µs
            add-atom:      23.999µs

  TOTAL: 37.289375265s

  Using ^2.0.0 as constraint for direct dep github.com/Yitsushi/go-commander
  Locking in 2.0.0 (6b77592) for direct dep github.com/Yitsushi/go-commander
  Locking in master (1f92242) for transitive dep golang.org/x/net
  Locking in v0.4.2 (f533f7a) for transitive dep github.com/Microsoft/go-winio
  Locking in v2.6.1 (a25b9ef) for transitive dep github.com/docker/distribution
  Using master as constraint for direct dep github.com/fsouza/go-dockerclient
  Locking in master (4bc6a18) for direct dep github.com/fsouza/go-dockerclient
  Locking in master (3573b8b) for transitive dep github.com/hashicorp/go-cleanhttp
  Locking in master (0e01648) for transitive dep golang.org/x/sys
  Locking in v1.0.0 (202f255) for transitive dep github.com/sirupsen/logrus
  Locking in v0.0.8 (941b50e) for transitive dep github.com/mattn/go-colorable
  Locking in v1.0.0 (202f255) for transitive dep github.com/Sirupsen/logrus
  Locking in master (ae77be6) for transitive dep github.com/kardianos/osext
  Locking in v1.13.1 (092cba3) for transitive dep github.com/docker/docker
  Locking in v0.8.0 (645ef00) for transitive dep github.com/pkg/errors
  Using v2 as constraint for direct dep gopkg.in/yaml.v2
  Locking in v2 (cd8b52f) for direct dep gopkg.in/yaml.v2
  Locking in v0.1.1 (baf6536) for transitive dep github.com/opencontainers/runc
  Using ^1.5.0 as constraint for direct dep github.com/fatih/color
  Locking in v1.5.0 (570b54c) for direct dep github.com/fatih/color
  Locking in v0.2.1 (990a1a1) for transitive dep github.com/docker/go-connections
  Locking in v0.0.2 (fc9e8d8) for transitive dep github.com/mattn/go-isatty
  Locking in v0.3.1 (f2d77a6) for transitive dep github.com/docker/go-units
  Locking in master (19f72df) for transitive dep github.com/Azure/go-ansiterm
safe write of manifest and lock: error while writing out vendor tree: error while exporting github.com/sirupsen/logrus: /var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/.gitignore already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/.travis.yml already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/CHANGELOG.md already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/LICENSE already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/README.md already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/alt_exit.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/alt_exit_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/doc.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/entry.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/entry_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/examples/basic/basic.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/examples/hook/hook.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/exported.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/formatter.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/formatter_bench_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/hook_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/hooks.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/hooks/syslog/README.md already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/hooks/syslog/syslog.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/hooks/syslog/syslog_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/hooks/test/test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/hooks/test/test_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/json_formatter.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/json_formatter_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/logger.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/logger_bench_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/logrus.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/logrus_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/terminal_appengine.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/terminal_bsd.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/terminal_linux.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/terminal_notwindows.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/terminal_solaris.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/terminal_windows.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/text_formatter.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/text_formatter_test.go already exists, no checkout
/var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep843060556/vendor/github.com/sirupsen/logrus/writer.go already exists, no checkout
: exit status 128

What did you expect to see?
For it to work.
What did you see instead?
Did not work and failed with error message.
safe write of manifest and lock: error while writing out vendor tree: error while exporting github.com/sirupsen/logrus: /var/folders/1n/k6w9b2g51hg_dhlh_c8q9q8r0000gn/T/dep777414686/vendor/github.com/sirupsen/logrus/.gitignore already exists, no checkout

You have github.com/sirupsen/logrus and github.com/Sirupsen/logrus in your dependency graph (note the difference in cases) since some of your dependencies still import github.com/Sirupsen/logrus.
We had an approach to this as described in  https://github.com/sirupsen/logrus/issues/553#issuecomment-307486868 but no one got to implement it yet. 😩

Well my dependencies have that. Damn that's not nice. :-( is there any kind of workaround for that?

I'm afraid that you can't solve this without updating dependencies at the moment (until we handle this case in dep).

But it's a transient dependency. I can't fix it. :( I don't depend on it. Some of my dependencies depend on it. How can I fix THAT? :)

@Skarlso yeah, until we fix it and fold cases together correctly, the only recourse you have is asking upstream to make the fix. Or, forking upstream and fixing it yourself, then pointing the import path to your fork with a source: directive in Gopkg.toml.

Oh I see. Thanks @sdboyer. :-)

Would case folding require changes to the go tool or compiler?
(Assuming import paths remained mixed case).

@sdboyer's proposed solution doesn't require any changes to go toolchain or compiler. We can handle this within dep (more specifically, within gps).

So, Glide solves this with a --force flag, which detects if there was a change in a repo path, and if yes, it overrides the previous one and uses that. It's dirty, but it does work. :) For brevity, and because I dislike slack (:P) I'm going to put the proposed solution here as well.

the system that deduces repo/project roots from import paths needs to be expanded to return some kind of informational structure of case sensitivity for different elements of the paths
the system that manages repositories on disk needs to learn how to read those case sensitivity info structures, and we'll need a new trie implementation that works with them
the solver itself will need to stop using simple map[string]<...> types, and use a custom map that, again, works with these case sensitivity info structures

at least, this is what a "proper" solution looks like
but the risk and complexity of that is considerable, so we'll likely have to settle for some harm reductive approaches in the meantime
but yeah, i need to strategize a bit so that i can break this up into issues

Even glide has a similar issue. You won't be able to install the dependencies for the code below if you are on a case-insensitive file system. And the real issue for me is that version selection was done twice (once for each case), and therefore you could have 2 versions of the same dependency.
package glidetest

import (
	l1 "github.com/Sirupsen/logrus"
	l2 "github.com/sirupsen/logrus"
)

func main() {
	_ = l1.New()
	_ = l2.New()
}

Ahhh totally forgot that that doesn't work. Right you are @ibrasho.

After #813 I made a naive attempt to resolve this by changing references from Sirupsen to sirupsen, but that turned out to be way too naive, since there are dependencies in the vendor directory that import Sirupsen/logrus, and that haven't been updated to sirupsen. So IMO this definitely requires a workaround of some type in dep. Who ever thought it would be OK to have a case-insensitive filesystem anyway!

This is also breaking our usage of dep in a Windows environment. Should dep be aware that it is running in a case-insensitive filesystem and in that case use the existing (the first one created wins) git repo?

@davidovich we may have to resort to something like that in order to stop the bleeding, but it's a pretty fundamental violation of dep's rules to do that. so, yeah...temporary. god, i hope 😨

Is there an easy way to tell what transitive dependency is importing Sirupsen/logrus (with a capital S)?

@tejasmanohar not currently, but #1079 will make it trivial.

(1/1) failed to export github.com/sirupsen/logrus: /var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/.gitignore already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/.travis.yml already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/CHANGELOG.md already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/LICENSE already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/README.md already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/alt_exit.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/alt_exit_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/appveyor.yml already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/doc.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/entry.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/entry_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/example_basic_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/example_hook_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/exported.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/formatter.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/formatter_bench_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/hook_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/hooks.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/hooks/syslog/README.md already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/hooks/syslog/syslog.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/hooks/syslog/syslog_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/hooks/test/test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/hooks/test/test_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/json_formatter.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/json_formatter_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/logger.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/logger_bench_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/logrus.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/logrus_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/terminal_bsd.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/terminal_linux.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/text_formatter.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/text_formatter_test.go already exists, no checkout
/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/writer.go already exists, no checkout
: command failed: [git checkout-index -a --prefix=/var/folders/q_/4bc8zypd4h96hvj_bjksfsq80000gp/T/dep173764965/vendor/github.com/sirupsen/logrus/]: exit status 128
safe write of manifest and lock: error while writing out vendor tree: failed to write dep tree

@kumarsiva07 right now, it takes a lot of manual work. once #1079 is in, dep should find a solution for you.
given that you're just trying to get over the initial hump, you might try compiling dep from that PR and running dep init for your case. at minimum, you should get a more useful error, and we could use some real-world testing of this!

I'm still encountering this on OSX with recent dep (1dc2d8b6)

@therealplato yeah I saw your note in slack - I'm honestly confused about how you arrived there 😢

i arrived there by trying to use a top-level vendor folder with leftover cruft in subfolders from old vendoring @sdboyer
@spenczar provided a workaround (at least for me on OSX)

delete all folders with unwanted capitalization
commit that deletion
dep ensure

One option could be to allow exclusion of transitive dependencies, no?

Actually, it's already possible, it seems!
ignored = ["github.com/Sirupsen/logrus"]

[[override]]
  name = "github.com/sirupsen/logrus"
  version = "^1.0.5"

@therealplato that also does not make sense. dep prepares its vendor folder in a separate dir, then moves it into place.
im honestly not sure if an ignore like that would have the desired effect. it...might, but it also might have some weird side effects, as I can't recall how we deal with case normalization in ignores.

Well, at least the vendor directory seems clean.
$ find . -name logrus
./vendor/github.com/sirupsen/logrus

authors: Skarlso davidovich ibrasho kumarsiva07 nathany pires rfay sdboyer tejasmanohar therealplato

repo: golang/dep

license_source: bigquery


text:
cmd/asm: document conditional jumps and branches

cmd/old6a and cmd/old8a document the conditional jumps, e.g.:
	{"JOS", LTYPER, x86.AJOS},  /* overflow set (OF = 1) */
	{"JO", LTYPER, x86.AJOS},   /* alternate */
	{"JOC", LTYPER, x86.AJOC},  /* overflow clear (OF = 0) */
	// lots more...

Let's bring that documentation with us to the new assembler, and cover the other platforms as well.

Let's also add docs to ARM.
It might also be helpful to pull in some of @minux's commentary from https://groups.google.com/forum/#!topic/golang-dev/MieNQcSAQNk about the carry flags, or link to it.

X86 is done, I believe.
"Add docs to ARM" is a fine thing to ask for, but what docs, and where? Also, putting this in the source for the assembler seems  like a poor choice.
Please explain what you want documented or close the issue.

I'll add docs next time I need them.

authors: josharian robpike

repo: golang/go


text:
cmd/cgo: panic instead of error for insufficient arguments to C function

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
go 1.7 beta 2

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

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.

https://play.golang.org/p/4NVQYgjnhx

What did you expect to see?
A compile error

What did you see instead?

panic: runtime error: index out of range

goroutine 1 [running]:
panic(0x5876a0, 0xc4200141d0)
	/usr/local/go/src/runtime/panic.go:500 +0x1a1
main.(*Package).rewriteCall(0xc42001c5a0, 0xc42000a240, 0xc420014b10, 0xc420090300)
	/usr/local/go/src/cmd/cgo/gcc.go:628 +0x1645
main.(*Package).rewriteCalls(0xc42001c5a0, 0xc42000a240)
	/usr/local/go/src/cmd/cgo/gcc.go:593 +0x167
main.(*Package).Translate(0xc42001c5a0, 0xc42000a240)
	/usr/local/go/src/cmd/cgo/gcc.go:170 +0x112
main.main()
	/usr/local/go/src/cmd/cgo/main.go:290 +0x726

It seems that Issue 13423 isnt fully fixed because the check can break early in the presence of void pointers as shown in the code example so it can still get out of bounds

I'm going to tentatively put this in Go 1.7, but realistically it will probably get pushed to 1.8.

authors: qeedquan quentinmit


text:
x/net/webdav: displayname is not escaped

What version of Go are you using (go version)?
go version go1.7.1 linux/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build168478790=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?
go run src/golang.org/x/net/webdav/litmus_test_server.go
curl http://localhost:9999/%3C -X PROPFIND -X MKCOL
curl http://localhost:9999/%3C -X PROPFIND -H "Depth: 0"

What did you expect to see?
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/%3C</D:href>
    <D:propstat>
      <D:prop>
        <D:getlastmodified>Mon, 19 Sep 2016 12:08:16 GMT</D:getlastmodified>
        <D:supportedlock>
          <D:lockentry xmlns:D="DAV:">
            <D:lockscope>
              <D:exclusive/>
            </D:lockscope>
            <D:locktype>
              <D:write/>
            </D:locktype>
          </D:lockentry>
        </D:supportedlock>
        <D:resourcetype>
          <D:collection xmlns:D="DAV:"/>
        </D:resourcetype>
        <D:displayname><</D:displayname>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

What did you see instead?
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/%3C</D:href>
    <D:propstat>
      <D:prop>
        <D:getlastmodified>Mon, 19 Sep 2016 12:08:16 GMT</D:getlastmodified>
        <D:supportedlock>
          <D:lockentry xmlns:D="DAV:">
            <D:lockscope>
              <D:exclusive/>
            </D:lockscope>
            <D:locktype>
              <D:write/>
            </D:locktype>
          </D:lockentry>
        </D:supportedlock>
        <D:resourcetype>
          <D:collection xmlns:D="DAV:"/>
        </D:resourcetype>
        <D:displayname><</D:displayname>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

Proposed fix:
https://github.com/koofr/go-webdav/commit/512e9d6154aea6972b36b4b9f0ab1c6e114a8891

Thanks for the report! We can only accept fixes to Go via Gerrit, though. See https://golang.org/doc/contribute.html

https://go-review.googlesource.com/#/c/29297/

authors: bancek bradfitz


text:
plugin: add "buildmode=plugin" support on PowerPC

Hi,
Do you have plans on supporting plugins on PowerPC?
ppc64le is of particular interest (at least for me and my company :))

/cc @laboger @ceseo

Looks like Lynn added it in CL 55850 and it is also mentioned in the draft release notes for 1.10 (https://beta.golang.org/doc/go1.10#compiler). I think it should therefore be working in the beta1 version of 1.10. The final release should be available in February 2018. If you are able to try out the beta now then that would be great.
I'm going to close this issue as a duplicate of #20756. Feel free to open new issues if you run into bugs while using the beta.

Thank you. I'll try the beta.
Sorry for producing a duplicate. I searched Opened issues only before submitting this one. Since the original one is closed, I didn't notice it.

authors: AndreyNevolin mundaym


text:
cmd/link: TestDWARF fails with the latest tip version

What did you do?
Just try to rebuild the latest tip version with all.bash
What did you expect to see?
No error on the build.
What did you see instead?
ok  	cmd/internal/test2json	0.252s
--- FAIL: TestDWARF (5.71s)
    --- FAIL: TestDWARF/testprogcgo (3.89s)
    	dwarf_test.go:145: did not find file:line for 0x40b9630 (main.main)
FAIL
FAIL	cmd/link	6.191s
ok  	cmd/link/internal/ld	96.030s

Does this issue reproduce with the latest release (go1.10.2)?
N/A
System details
go version devel +eeff8fa453 Mon May 14 20:33:00 2018 +0000 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/yoshiki/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/yoshiki/gocode:/Users/yoshiki/exercises/gpl:/Users/yoshiki/oak"
GORACE=""
GOROOT="/Users/yoshiki/tools/go"
GOTMPDIR=""
GOTOOLDIR="/Users/yoshiki/tools/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
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/pb/c7_4_d355ng5zfm4r_jg2gg00000gn/T/go-build881657275=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version devel +eeff8fa453 Mon May 14 20:33:00 2018 +0000 darwin/amd64
GOROOT/bin/go tool compile -V: compile version devel +eeff8fa453 Mon May 14 20:33:00 2018 +0000
uname -v: Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.4
BuildVersion:	17E202
lldb --version: lldb-900.0.50.1
  Swift-4.0

@dr2chase, looks like this was introduced by https://github.com/golang/go/commit/7bac2a95f65418ec18d1fb5f30ae47e91980f30c

I am unable to reproduce this on linux.
$gotip test -v cmd/link
=== RUN   TestDWARF
=== RUN   TestDWARF/testprog
=== RUN   TestDWARF/testprogcgo
--- PASS: TestDWARF (0.72s)
    --- PASS: TestDWARF/testprog (0.26s)
    --- PASS: TestDWARF/testprogcgo (0.37s)
=== RUN   TestDWARFiOS
--- SKIP: TestDWARFiOS (0.00s)
	dwarf_test.go:162: skipping on non-darwin/amd64 platform
=== RUN   TestLargeSymName
--- PASS: TestLargeSymName (0.00s)
=== RUN   TestIssue21703
--- PASS: TestIssue21703 (0.08s)
=== RUN   TestLargeText
--- SKIP: TestLargeText (0.00s)
	linkbig_test.go:24: Skipping large text section test in short mode or on amd64

I am unable to reproduce this on Darwin.
I've been running all.bash all along.
I did recently upgrade my XCode (yesterday-recently).
go version devel +c64c2ce812 Mon May 14 16:12:59 2018 -0400 darwin/amd64

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/drchase/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/drchase/GoogleDrive/work/gocode"
GORACE=""
GOROOT="/Users/drchase/GoogleDrive/work/go"
GOTMPDIR=""
GOTOOLDIR="/Users/drchase/GoogleDrive/work/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
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/gr/vvb66dqx6jl6lh8wckfd5p9w0095tn/T/go-build292785485=/tmp/go-build -gno-record-gcc-switches -fno-common"

uname -v
Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64

lldb --version
lldb-902.0.79.2
  Swift-4.1

I'll see if I can figure out what other information would be helpful to figure out what's causing this.

FWIW testDWARF is called with multiple build modes -- it would be helpful to know which one is failing (also version info for clang).

The problem still occurs on my MacBook. The following is the version information of clang:
MacBook-61:src yoshiki$ clang --version
Apple LLVM version 9.0.0 (clang-900.0.38)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
MacBook-61:src yoshiki$

I tried with MacBook Air. The problem didn't occur. The version information of clang on the MacBook Air is following:
Yoshiki-no-MacBook-Air:~ yoshiki$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Yoshiki-no-MacBook-Air:~ yoshiki$

The clang on my MacBook Air is newer than one on my MackBook.

After upgrading XCode and clang, the problem disappeared.
MacBook-61:~ yoshiki$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
MacBook-61:~ yoshiki$

Thanks for the analysis @YoshikiShibata !
@dr2chase - This matches with your findings since you mentioned that you upgraded xcode recently.

You didn't perhaps save the binary produced with the older version of XCode?  I'd love to see what it did differently.

I think this issue should be reopened. It looks like some (most?) versions of dsymutil do not support (but see below) version 3 for debug_line, including the most recent version of dsymutil on 10.12.
If 10.12 is still considered supported this breaks backwards compatibility.
Now, Saying that dsymutil doesn't support v3 is incomplete, it seems that it actually does, but only if you lie to it and say it's v2. For example this is what the line table of a compilation unit produced by clang looks like in the final executable:
  Offset:                      0x2b3fc
  Length:                      154
  DWARF Version:               2
  Prologue Length:             30
  Minimum Instruction Length:  1
  Initial value of 'is_stmt':  1
  Line Base:                   -5
  Line Range:                  14
  Opcode Base:                 13

 Opcodes:
  Opcode 1 has 0 args
  Opcode 2 has 1 args
  Opcode 3 has 1 args
  Opcode 4 has 1 args
  Opcode 5 has 1 args
  Opcode 6 has 0 args
  Opcode 7 has 0 args
  Opcode 8 has 0 args
  Opcode 9 has 1 args
  Opcode 10 has 0 args
  Opcode 11 has 0 args
  Opcode 12 has 1 args

Note how it says version 2 but has more than 9 standard opcodes.
The choice is between lying, pretending 10.12 doesn't exist or reverting the prologueEnd thing.

It is still broken for me.
~/golang/src (master=) % go test cmd/link
--- FAIL: TestDWARF (3.29s)
    --- FAIL: TestDWARF/testprogcgo (2.75s)
    	dwarf_test.go:145: did not find file:line for 0x40b98d0 (main.main)
FAIL
FAIL	cmd/link	29.611s
~/golang/src (master=) % go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/thorn/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/thorn/go"
GORACE=""
GOROOT="/Users/thorn/golang"
GOTMPDIR=""
GOTOOLDIR="/Users/thorn/golang/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
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/km/50gy6_q557v6_7vxbf9b29v00000gn/T/go-build027945066=/tmp/go-build -gno-record-gcc-switches -fno-common"
~/golang/src (master=) % uname -v
Darwin Kernel Version 15.6.0: Tue Jan 30 11:45:51 PST 2018; root:xnu-3248.73.8~1/RELEASE_X86_64

I can confirm that setting the DWARF version on .debug_lines to 2 still works okay on 10.13.4 with corresponding XCode.

authors: YoshikiShibata aarzilli agnivade dr2chase meirf thanm ysmolsky


text:
syscall: TestCloneNEWUSERAndRemapNoRootDisableSetgroups fails on CentOS 7

On CentOS 7, had an error on test TestCloneNEWUSERAndRemapNoRootDisableSetgroups test.
On Fedora28, all tests are sucessfull.
There is a previous Issue on the same matter #11261.
But in my case the message is different: "invalid argument, output:"
What version of Go are you using (go version)?
go version go1.10.3 linux/amd64
Does this issue reproduce with the latest release?
yes. i tried tip
What operating system and processor architecture are you using (go env)?
$ uname -a
Linux geoserver.localdomain 3.10.0-862.6.3.el7.x86_64 #1 SMP Tue Jun 26 16:32:21 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/centos-release
CentOS Linux release 7.5.1804 (Core)

$ getenforce
Disabled

$go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/scatex/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/scatex/go"
GORACE=""
GOROOT="/home/scatex/wrk/go"
GOTMPDIR=""
GOTOOLDIR="/home/scatex/wrk/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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-build047489229=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Checkout go source code
Execute command go/src/all.bash

What did you expect to see?
No errors on test phase.
What did you see instead?
...
...
ok      sync/atomic     0.067s
--- FAIL: TestCloneNEWUSERAndRemapNoRootDisableSetgroups (0.00s)
        exec_linux_test.go:116: Cmd failed with err fork/exec /usr/bin/whoami: invalid argument, output:
--- FAIL: TestCloneNEWUSERAndRemapNoRootSetgroupsEnableSetgroups (0.00s)
        exec_linux_test.go:156: Unprivileged gid_map rewriting with GidMappingsEnableSetgroups must fail
--- FAIL: TestEmptyCredGroupsDisableSetgroups (0.00s)
        exec_linux_test.go:164: fork/exec /usr/bin/whoami: invalid argument
FAIL
FAIL    syscall 0.044s
ok      testing 2.007s
...
...
...
ok      cmd/vet/internal/cfg    0.026s
2018/07/14 06:40:54 Failed: exit status 1

CC @LK4D4

Output for command:
$ strace -f go test syscall -test.run=TestCloneNEWUSERAndRemapNoRootDisableSetgroups
strace.txt

The test passes now, after I changed some kernel settings:
grubby --args="namespace.unpriv_enable=1 user_namespace.enable=1" --update-kernel="/boot/vmlinuz-3.10.0-862.6.3.el7.x86_64"
echo "user.max_user_namespaces=15076" >> /etc/sysctl.conf
But it was completely uninformed!
Just following generic recipes from web.

On some other Issue, someone asked to run this command.
In my case, the error message is "Invalid Argument".
(the same message on failed test)
$ unshare -Ur
unshare: unshare failed: Invalid argument

I just realized there was previous Issues about this ... sorry for duplication:
https://go-review.googlesource.com/c/go/+/49311

It looks like now CentOS 7 has unprivileged namespaces disabled by default with kernel parameter.
The thing to check would be if it is CentOS 7 and there is namespace.unpriv_enable=1 in /proc/cmdline, but it's not the first time we add band-aid for CentOS 7. Maybe it's easier just to add some comment to file like "Please find how to enable unprivileged namespaces for your distribution if you want these tests to work properly".

Is there some way we can detect CentOS and just skip the test?  Perhaps look in /etc/lsb-release?

Maybe it's easier just to add some comment to file like "Please find how to enable unprivileged namespaces for your distribution if you want these tests to work properly".

In general the tests have to pass for users who don't understand what the code does.  So while that would be easier for us, it would just be mystifying for most people installing Go.  If the test can't reliably pass, we have to just skip it.

@ianlancetaylor Yeah, apparently all centos releases have /etc/centos-release file, maybe we can just check its presence

In general the tests have to pass for users who don't understand what the code does.
It's me!

Can I have a try on the fix ?
(check if /etc/centos-release presence)

@EduRam Sure, send a fix, if you can do it very soon for the 1.11 release.  Thanks.

authors: EduRam LK4D4 ianlancetaylor


text:
differing results writing []byte to stdout in win and linux

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

$ go version
win: go version go1.13 windows/amd64
linux: go version go1.10.1 linux/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
go version go1.13 windows/amd64
go version go1.10.1 linux/amd64

What did you do?

run code
package main

import(
	"os"
)

func main() {
	data := make([]byte, 128)
	os.Stdout.Write(data)
	os.Stdout.Write([]byte("end"))
}

What did you expect to see?
result equal in linux and win
What did you see instead?

This is likely just because of how the different terminal applications display null bytes.
Try writing printable characters, like 'A'.

This doesn't have anything to do with Go.  The same thing would happen with a similar program in a language like C.  Closing.  Please comment if you disagree.

I don't know this, I just think that the results are different on different platforms.

Yes, the output is different on different platforms.  It's just that that doesn't have anything to do with Go.  It's because different platforms are different.

authors: ericlagergren eudore ianlancetaylor


text:
x/build/cmd/coordinator: doesn't support trybots on custom branches in golang.org/x repos

There appears to be no support for running trybots on branches other than master and release-branch.goX.Y in golang.org/x repos. It may be a matter of configuring more than 0 builders to run for such branches, or it may require more work in coordinator; this needs investigation.
This happened in https://golang.org/cl/221378, which was a CL into the gopls-release-branch.0.3 branch of golang.org/x/tools repo.
/cc @toothrot @cagedmantis @stamblerre @heschik

I can take a look at implementing this if it's not prioritized. It'd be really helpful to have TryBots run before I make agopls release.

It may be a matter of configuring more than 0 builders to run for such branches, or it may require more work in coordinator; this needs investigation.

It would be helpful to figure out the reason this isn't working now. Feel free to investigate this and update the issue. Once we know what needs to be done, it'll be easier to fix this. Thanks!

I'm not very familiar with the code in cmd/coordinator.go, but my suspicion is that https://cs.opensource.google/go/build/+/master:cmd/coordinator/coordinator.go;drc=2c615328112ac3d7af87e5cf172d69f0e1bc8364;l=1205 might be the problem. From what I understand, work.Branch will be something like gopls-release-branch.0.4, while work.GoBranch will contain other branch names that never match. When goRev is empty, newBuild fails, resulting in no TryBots in the set. It seems like it works for x/ repos on master because it matches on "master".
@dmitshur: How do you suggest we fix this issue? Should x/repo branches run only with Go at tip or with previous releases as well?

@stamblerre Thanks for looking into this, that's very helpful.
What you described above sounds plausible. As a next step, let's try to confirm it. When newBuild fails, it prints a "can't create build for ..." message to the logs. We can try starting a trybot run on a "gopls-release-branch.0.4" branch, then check coordinator logs for that message.

Should x/repo branches run only with Go at tip or with previous releases as well?

The current policy explicitly mentions that it applies to "master" branch only:
// For subrepos on the "master" branch, test against prior releases of Go too.

So let's start by fixing this issue so that golang.org/x repo CLs on non-master branches are tested with Go at tip only. Afterwards, we can consider expanding it to cover prior Go releases.
Also, I've checked the dashboard configuration, and it reports that many builders should run for this target configuration:
// +build ignore

package main

import (
	"fmt"

	"golang.org/x/build/dashboard"
)

func main() {
	// TryBuildersForProject returns the builders that should run as part of
	// a TryBot set for the given project.
	// The project argument is of the form "go", "net", "sys", etc.
	// The branch is the branch of that project ("master", "release-branch.go1.12", etc)
	// The goBranch is the branch of Go to use. If proj == "go", then branch == goBranch.
	const (
		proj     = "tools"
		branch   = "gopls-release-branch.0.4"
		goBranch = "master"
	)
	builders := dashboard.TryBuildersForProject(proj, branch, goBranch)
	for _, b := range builders {
		fmt.Println(b.Name)
	}

	// Output:
	// freebsd-amd64-12_0
	// linux-386
	// linux-amd64
	// linux-amd64-race
	// openbsd-amd64-64
	// windows-386-2008
	// windows-amd64-2016
}

Which suggests this is indeed a bug in cmd/coordinator rather than a misconfiguration in x/build/dashboard.

Yep, I saw the same thing when I tried writing a test for this. I just triggered TryBots on https://golang.org/cl/227418 - I'm not sure how to see the logs though - would you mind taking a look?
Having the tests run with tip Go sounds reasonable to me. I think I should be able to put together a CL for that.

I just triggered TryBots on https://golang.org/cl/227418 - I'm not sure how to see the logs though - would you mind taking a look?

Sure. I couldn't see logs far enough back for that CL, but I just sent CL 227444 while tailing logs, and saw this:
2020/04/07 21:39:01 Starting new trybot set for {tools gopls-release-branch.0.4 Idb726bed70bab8880d752f346026b66e1885425c 54a1afaa050ab8df50ca7358372cc305d184717c}
2020/04/07 21:39:01 can't create build for {"freebsd-amd64-12_0" "" "tools" "54a1afaa050ab8df50ca7358372cc305d184717c"}: required field Rev is empty; got {Name:freebsd-amd64-12_0 Rev: SubName:tools SubRev:54a1afaa050ab8df50ca7358372cc305d184717c}
2020/04/07 21:39:01 can't create build for {"linux-386" "" "tools" "54a1afaa050ab8df50ca7358372cc305d184717c"}: required field Rev is empty; got {Name:linux-386 Rev: SubName:tools SubRev:54a1afaa050ab8df50ca7358372cc305d184717c}
2020/04/07 21:39:01 can't create build for {"linux-amd64" "" "tools" "54a1afaa050ab8df50ca7358372cc305d184717c"}: required field Rev is empty; got {Name:linux-amd64 Rev: SubName:tools SubRev:54a1afaa050ab8df50ca7358372cc305d184717c}
2020/04/07 21:39:01 can't create build for {"linux-amd64-race" "" "tools" "54a1afaa050ab8df50ca7358372cc305d184717c"}: required field Rev is empty; got {Name:linux-amd64-race Rev: SubName:tools SubRev:54a1afaa050ab8df50ca7358372cc305d184717c}
2020/04/07 21:39:01 can't create build for {"openbsd-amd64-64" "" "tools" "54a1afaa050ab8df50ca7358372cc305d184717c"}: required field Rev is empty; got {Name:openbsd-amd64-64 Rev: SubName:tools SubRev:54a1afaa050ab8df50ca7358372cc305d184717c}
2020/04/07 21:39:01 can't create build for {"windows-386-2008" "" "tools" "54a1afaa050ab8df50ca7358372cc305d184717c"}: required field Rev is empty; got {Name:windows-386-2008 Rev: SubName:tools SubRev:54a1afaa050ab8df50ca7358372cc305d184717c}
2020/04/07 21:39:01 can't create build for {"windows-amd64-2016" "" "tools" "54a1afaa050ab8df50ca7358372cc305d184717c"}: required field Rev is empty; got {Name:windows-amd64-2016 Rev: SubName:tools SubRev:54a1afaa050ab8df50ca7358372cc305d184717c}

Thank you for making a CL, I'll review it next.

authors: dmitshur stamblerre


text:
cmd/trace: crash because of deprecated HTML Imports in web view

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

go version go1.14 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
Chrome 80.0.3987.132 MacOS
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/max/Library/Caches/go-build"
GOENV="/Users/max/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/max/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14/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/rg/bvn53d7j0wbfnxkw_fktlsq40000gn/T/go-build837065189=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Run the go trace tool:go tool trace -http=':8081' trace.out on any trace. Then, navigate to to View Trace. This page is using a HTML imports, which have been deprecated in Chrome M80.
What did you expect to see?
The trace tool.
What did you see instead?
An empty page and an error in the console:
HTML Imports is deprecated and has now been removed as of M80. See https://www.chromestatus.com/features/5144752345317376 and https://developers.google.com/web/updates/2019/07/web-components-time-to-upgrade for more details.
Uncaught ReferenceError: tr is not defined
    at onResult (trace:59)
    at trace:43

should be fixed in 14.1 #37343

Duplicate of #34374

authors: andybons mmathys seankhliao


text:
cmd/go2go: unexpected type parameter panic in translator

Extracted from #39758: The following program
package main

type top(type T, T2) struct {
	p *parent(T, T2)
}

type parent(type T, T2) struct {
	(child(T, T2))
}

type child(type T, T2) struct {
	T2
}

func (d *top(T, T2)) foo() *T {
	// panic: internal error: receiver type parameter inference failed
	// t, _ := d.p.foo()

	// panic: -: unexpected type string character '₇' in "T₇"
	t, _ := d.p.child.foo()
	return t
}

func (rb *child(T, T2)) foo() (*T, bool) {
	return nil, true
}

func main() {
	var _ top(int, int)
}

type-checks ok but the translator reports
$ go tool go2go run main.go2
panic: unexpected type parameter

goroutine 1 [running]:
go/go2go.(*translator).typeToAST(0xc0001a5678, 0x12e40a0, 0xc00012ae80, 0xc00011d6e0, 0xc0001a4c78)
	/Users/gri/go/src/go/go2go/types.go:596 +0x1725
go/go2go.(*translator).typeListToASTList(0xc0001a5678, 0xc00011cf80, 0x2, 0x2, 0x0, 0x0, 0xc0001241f8, 0xc0001a4b68, 0x1003598, 0x12570c0)
	/Users/gri/go/src/go/go2go/rewrite.go:1175 +0xe5
go/go2go.(*translator).lookupInstantiatedType(0xc0001a5678, 0xc0001366c0, 0x0, 0x0, 0x0)
	/Users/gri/go/src/go/go2go/rewrite.go:1095 +0x2b6
go/go2go.(*translator).translateSelectorExpr(0xc0001a5678, 0xc00011c780)
	/Users/gri/go/src/go/go2go/rewrite.go:804 +0x5b1
go/go2go.(*translator).translateExpr(0xc0001a5678, 0xc00011c780)
	/Users/gri/go/src/go/go2go/rewrite.go:666 +0x4ba
go/go2go.(*translator).translateSelectorExpr(0xc0001a5678, 0xc00012a800)
	/Users/gri/go/src/go/go2go/rewrite.go:756 +0x71
go/go2go.(*translator).translateExpr(0xc0001a5678, 0xc00012a800)
	/Users/gri/go/src/go/go2go/rewrite.go:666 +0x4ba
go/go2go.(*translator).translateExpr(0xc0001a5678, 0xc0001046c0)
	/Users/gri/go/src/go/go2go/rewrite.go:685 +0x385
go/go2go.(*translator).translateExprList(0xc0001a5678, 0xc0001046c0, 0x1, 0x1)
	/Users/gri/go/src/go/go2go/rewrite.go:852 +0x46
go/go2go.(*translator).translateStmt(0xc0001a5678, 0xc00011c7e0)
	/Users/gri/go/src/go/go2go/rewrite.go:583 +0x29d
go/go2go.(*translator).translateBlockStmt(0xc0001a5678, 0xc000106de0)
	/Users/gri/go/src/go/go2go/rewrite.go:544 +0x57
go/go2go.(*translator).translateFuncDecl(0xc0001a5678, 0xc00011d5b0)
	/Users/gri/go/src/go/go2go/rewrite.go:534 +0xc5
go/go2go.(*translator).translate(0xc0001a5678, 0xc000140280)
	/Users/gri/go/src/go/go2go/rewrite.go:461 +0x391
go/go2go.rewriteAST(0xc00012a240, 0xc000126360, 0x0, 0x0, 0xc000101770, 0xc000140280, 0x2583701, 0xc00012a5c0, 0x14197e0)
	/Users/gri/go/src/go/go2go/rewrite.go:257 +0xe5
go/go2go.rewriteFile(0xc00017a0a0, 0x43, 0xc00012a240, 0xc000126360, 0x0, 0x0, 0xc000101770, 0xc00017a230, 0x4c, 0xc000140280, ...)
	/Users/gri/go/src/go/go2go/rewrite.go:221 +0xb8
go/go2go.rewriteFilesInPath(0xc000126360, 0x0, 0x0, 0xc00017a0a0, 0x43, 0xc000104480, 0x1, 0x1, 0x0, 0x0, ...)
	/Users/gri/go/src/go/go2go/go2go.go:114 +0xc5c
go/go2go.rewriteToPkgs(0xc000126360, 0x0, 0x0, 0xc00017a0a0, 0x43, 0xc0001061a0, 0xc00017a0a0, 0x43, 0x7ffeefbffa96, 0x8)
	/Users/gri/go/src/go/go2go/go2go.go:46 +0x165
go/go2go.Rewrite(...)
	/Users/gri/go/src/go/go2go/go2go.go:30
main.translate(0xc000126360, 0xc00017a0a0, 0x43)
	/Users/gri/go/src/cmd/go2go/translate.go:15 +0x47
main.main()
	/Users/gri/go/src/cmd/go2go/main.go:54 +0xb25

Thanks, fixed on dev.go2go branch.

authors: griesemer ianlancetaylor


text:
register ABI: allow selecting ABI when Go code refers to assembly routine

[Note: this is a tracking issue, not a regular bug.]
In CL 260477 as part of the register ABI work (tracking issue 40724), the assembler was changed to add syntax for specifying the ABI (ABI0 vs ABIInternal) when defining a given assembler routine or referring to some other routine. This change made it possible to have finer control over "special" assembler routines that are defined and used in non-standard ways.
For example, a function such as runtime.panicIndex is called by the compiler using a custom ABI (not ABI0), hence in order to get the correct semantics, there had to be some way to insure that a call from Go code to runtime.panicIndex did not go through an ABIInternal->ABI0 wrapper.  Changing the assembly definition of runtime.panicIndex to have it be ABIInternal took care of this, but it is worth pointing out that declaring runtime.panicIndex as ABIInternal is something of a fiction, since the compiler currently doesn't follow the new ABIInternal rules exactly when emitting calls to the function.
The function runtime.goexit is another example: this function is never called, only used as a sentinel (e.g. the runtime takes its address, but never actually invokes it).  When the runtime takes its address, however, the actual PC of the function itself it needed, as opposed to taking the address of the ABIInternal->ABI0 wrapper for the function.  To resolve this problem, the assembly source for runtime.goexit was changed the to give it a definition as ABIInternal-- this meant that references from the runtime Go code would pick up the function directly, as opposed to the ABIInternal->ABI0 wrapper for it.  Again here things are a little misleading, since there will never be an ABIInternal call, or any other call, to runtime.goexit.
A third case comes up with syscall wrappers: for functions like the x509 assembly wrappers, if we take the address of the wrapper function from Go to pass it to a syscall, we have to insure that we get the function itself and not an ABIInternal->ABI0 wrapper.
To improve on this situation, it might make more sense to instead create some sort of mechanism at the Go level to allow control over which ABI is selected (this idea from @cherrymui). For example, something like
  //go:abi0
  func goexit() ...

would be a way to say, "Compiler, I know that this function is an assembly routine, but when I refer to it, I want to get the ABI0 symbol and not the ABIInternal->ABI0 wrapper for the symbol". The one potential drawback here is that once this pragma is used in the  package, we can no longer call the routine in question from Go within the package (if for some reason we need to have both direct calls and a reference that bypasses the ABI wrapper).
Another possibility would be to develop a pragma that applies to the referring expression itself, e.g.
  // Take address of "runtime.someAssemblyFunc", insuring that we get
  // the func itself and not the ABIInternal->ABI0 wrapper for the symbol
  myFuncPtr := unsafe.SelectABI(runtime.someAssemblyFunc, "ABI0")

An advantage of this second option would be that we could communicate to the compiler that a function uses an unknown or non-standard ABI, and should not be calllable directly from Go. Example:
  // Here 'anotherAssemblyRoutine' uses the C++ ABI, so ti should not  be called directly from Go.
  myCppFuncPtr := unsafe.SelectABI(runtime.anotherAssemblyRoutine, "ABIUnspecified")

  // legal (we're just storing the address)
  C.somestruct.cfuncptr = myCppFuncPtr

  // illegal-- generates a compiler error
  myCppFuncPtr(101, nil)

Unsure as to how much work either of these options would be to implement.  Also probably might make sense to restrict the use of these constructs to "runtime" packages (as we already do with the assembler feature).

(While I proposed the idea of using a pragma) I don't really like having many pragmas. And I'll note that the current approach (marking certain assembly functions as ABIInternal) "works". Personally I'd be fine just doing that.
From discussions, one problem of marking assembly functions as ABIInternal is that they are not really "ABIInternal", so marking them ABIInternal is somewhat a "lie". They are also not really ABI0 (at least for some of them). If we are aiming for clarity, we may want to mark them ABISpecial, either as assembly marker or as a pragma on the declarations in Go side. One counter argument is that their specialness is implementation detail, i.e. "internal", so ABIInternal is fine.
The unsafe.SelectABI is interesting but I don't know how to implement it. runtime.anotherAssemblyRoutine is not quoted, so it is an identifier in the Go code. How does the compiler resolve that identifier? Do you still need a declaration? What is its result type? (Maybe unsafe.Pointer or uintptr? So you can pass it to other places where the PC is expected, but cannot call it without explicitly cast it to a function pointer.) I would say this mechanism is for a limited set of special functions. We probably don't want to make it a public API (as in the unsafe package). Also, it probably doesn't make sense for other implementations of Go.

A few notes:
"once this pragma is used in the package, we can no longer call the routine in question from Go within the package"
is something we could support, since that is actually the transition plan for getting to the new ABI -- enable it for testing with a pragma, till it works, then throw the big switch.  We could keep the old plumbing (which is already working in development as them no-register case of a register ABI.  This would not be hard; we could probably never call such a method with reflection, as a goroutine, etc, but we could probably ensure that with static checks, or at least vet checks.
I'm torn on the too-many-pragmas question.

we hate knobs, and these are knobs.
I don't think they are under the compatibility guarantee, which is good.
not adding more pragmas, but then overloading existing mechanisms to mean the thing we didn't want to add a pragma for, is, actually, adding a knob.  Knobs are technical debt, but overloaded multifunction knobs are also technical debt.

I'm a little interested in the unsafe thing -- we can certainly see constant strings in the compiler (certainly in SSA, we have optimizations on constants already), we could probably make that work, too.

CL https://go-review.googlesource.com/c/go/+/290029 is an alternative approach: directly taking the address in assembly, and only pass the address to Go, as the Go side only needs the address. Then we don't need the ABI markers (because it is local to assembly now).

authors: cherrymui dr2chase thanm


text:
JSON Decoding Performance

Go Version: go version go1.14 linux/amd64
go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/nlp/.cache/go-build"
GOENV="/home/nlp/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/nlp/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/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-build531942507=/tmp/go-build -gno-record-gcc-switches"

I was quite surprised to see that JSON decoding in python is 2x faster than Go. Here is my setup:
To generate the json please run the following code:
import pandas as pd
d = [{'sentences': ['Sent', 'Sent1', 'Sent2'], 'content_id': 'String', 'id': 'String', 'date': '2000-03-28', 'label': '1', 'categories': ['String']}]
d = d*200000
df = pd.DataFrame(d)
df.to_json("./dummy.json",orient='records',lines=True)

Here is the comparison between python and go:
import json
with open("./dummy.json") as f:
    for index,line in enumerate(f):
        if index==100000:
            break
        json.loads(line)

package main

import (
	"encoding/json"
	"os"
)

func main() {
	file, _ := os.Open("./dummy.json")
	defer file.Close()
	data := map[string]interface{}{}
	decoder := json.NewDecoder(file)
	for i := 0; i < 100000; i++ {
		decoder.Decode(&data)
	}
}

Results:
Python:
real    0m0.425s
user    0m0.266s
sys     0m0.094s

Go(encoding/json)
real    0m0.591s
user    0m0.438s
sys     0m0.250s

Python seems to outperform Go. Also, the results don't vary even when I use the results i.e.
import json
result=[]
with open("./dummy.json") as f:
    for index,line in enumerate(f):
        if index==100000:
            break
        result.append(json.loads(line))

package main

import (
	"os"

	"github.com/goccy/go-json"
)

func main() {
	file, _ := os.Open("./dummy.json")
	defer file.Close()
	//data := map[string]interface{}{}
	result := make([]map[string]interface{}, 100000)
	decoder := json.NewDecoder(file)
	for i := 0; i < 100000; i++ {
		decoder.Decode(&result[i])
	}
}

Python Perf:
real    0m0.738s
user    0m0.500s
sys     0m0.172s

Go:
real    0m1.156s
user    0m1.016s
sys     0m0.328s

Note that the Python encode is written in C, it's not pure Python. So you're comparing Go with C.

How did you run these benchmarks? This looks like time output. I hope you did not measure go run.

See #40128 and https://github.com/golang/go/issues/40128#issuecomment-729278198 in particular. There's work on a a new decoder that is significantly faster.

Going to close this as a duplicate of all the other performance related issues that are more specific as this issue doesn't present a concrete suggestion on what to do for improving performance.

authors: ALTree albertnanda dsnet fzipp


text:
Semantic versioning constraint errors, with the "dep" package, on Darwin/ARM64

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

go version go1.16beta1 darwin/arm64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/tyson/Library/Caches/go-build"
GOENV="/Users/tyson/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/tyson/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/tyson/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.16beta1"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zq/4fmgrgv16fq9d_9jygw8ky4r0000gn/T/go-build2949034140=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Attempted to build the "dep" package (a dependency, for another project), under MacOS 11.2.3, on an ARM64 machine, with the latest beta version of Go.
What did you expect to see?
I would expect this package to build, although I have never tested this platform/Go version combination. (I previously used the x86-64 version of Go, under Rosetta 2).
What did you see instead?
tyson@Tysons-Air ~ % go get github.com/golang/dep/cmd/dep
# github.com/golang/dep/gps
go/pkg/mod/github.com/golang/dep@v0.5.4/gps/constraint.go:103:21: cannot use sv (type *semver.Version) as type semver.Version in field value
go/pkg/mod/github.com/golang/dep@v0.5.4/gps/constraint.go:122:16: invalid type assertion: c.(semver.Version) (non-interface type *semver.Constraints on left)
go/pkg/mod/github.com/golang/dep@v0.5.4/gps/constraint.go:149:4: undefined: semver.Constraint

That seems like a regular build error in the dep project. Is there a reason you're still using it? It has been deprecated and abandoned for two years now.

That seems like a regular build error in the dep project. Is there a reason you're still using it? It has been deprecated and abandoned for two years now.

Thanks. I didn't realise that it was deprecated - I'm new to working with Go, and it was a prerequisite, that was dragged in, whilst trying to bootstrap building https://github.com/lf-edge/eve's build tools, on the new M1 Macs. Is there's a suggested replacement for it?

It's the module system, see the dep deprecation notice in its readme:
https://github.com/golang/dep

The module system? It's actually very widely used at this point: https://blog.golang.org/survey2020-results#TOC_8.

The module system? It's actually very widely used at this point: https://blog.golang.org/survey2020-results#TOC_8.

Sorry, was referring to "Dep". :)

Yes, it's not surprising, it has been deprecated for a few years at this point.
I'm closing this issue then, since this is not a bug in Go.

authors: ALTree mvdan vmlemon


text:
math.Pow

s := math.Pow(float64(1.2), float64(1/9))
fmt.Println(s)
the result is 1, why not 1.0204645356768483 ???

s := math.Pow(float64(1.2), float64(1.0/9.0))
fmt.Println(s)

1/9 == 0

s := math.Pow(float64(8.0), float64(1.0/3.0))
fmt.Println(s)
1.9999999999999998
fmt.Println(float64(1.0 / 3.0))
0.3333333333333333

I agree, math.Pow(8, 1/3.) should be 2, not the float below 2. The actual result is closer to 2.
Proof: https://play.golang.org/p/BRHIwWv2iBB
Not sure what precision we guarantee for math.Pow.


text:
proposal: Go 2: spec: basic type inferred slice literals

Slices can be initialized with a brace-bound, comma separated list of literals along with the type preceding the braces:
A := []string{"a", "b", "c"}
var Y = []string{"x", "y", "z"}
L := []int{1, 2, 3}

Based on the feedback in https://github.com/golang/go/issues/12854, I propose users be able to omit the type on slices of basic types as an intermediate step. The code above may then be written as:
A := {"a", "b", "c"}
var Y = {"x", "y", "z"}
L := {1, 2, 3}
var Y2 []int = {9, 8, 7} // new way of declaring slices

It is my belief that issue #12854 is too great of a step in the right direction and the consequences of eliding many types could cause readability issues, as were discussed. I have deliberately excluded map and struct types from this proposal since they were a source of issues. By reducing the cases in which types may be elided we preserve one of the greatest strengths of Go: it's readability.
It is my argument that this does not impact the readability negatively since it only elides basic types. Whenever this syntax is seen in the wild it can easily be deduced to be one of the 6 "inferrable" basic types.
Some possible effects of the change
Casting types with underlying basic type:
import "example.org/pkg
// ...
type foo []int
c := foo({1, 2, 3})
d := pkg.Bar({"a", "c", "d"})

Go-time's idea on using gofmt to allow users to elide types
A while ago issue #12854 was discussed on the go-time podcast and there was a suggestion type eliding could be used by the programmer and when gofmt was run, it would add the type by itself. This could even be used as a fix in case type elision gets out of hand in the future and gophers agree we prefer to read typed composite literals.

related - https://github.com/golang/go/issues/12854

Now that we have generics, we could introduce slices.Of which could take an arbitrary list of values (of the same type) and return a slice of that type.
    A := slices.Of("a", "b", "c")

This would work for all kinds of values, not just literals.  Admittedly slices.Of is not short, but where it occurs frequently we could use a local function.

No further comments.

authors: deanveloper ianlancetaylor soypat


text:
x/vulndb/internal/worker: test failing since CL 382994

panic: no concrete method: func (*crypto/elliptic.nistCurve[*crypto/elliptic/internal/nistec.P224Point]).Add(x1 *math/big.Int, y1 *math/big.Int, x2 *math/big.Int, y2 *math/big.Int) (*math/big.Int, *math/big.Int)

goroutine 2270 [running]:
golang.org/x/tools/go/ssa.(*Program).declaredFunc(0xc0004b28f0, 0xc012700c30)
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/methods.go:124 +0xf9
golang.org/x/tools/go/ssa.(*Program).addMethod(0x11c0f70?, 0xc00f976a50, 0xc00e3b6cd0)
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/methods.go:86 +0x14a
golang.org/x/tools/go/ssa.(*Program).needMethods(0xc0004b28f0, {0x11c0f70?, 0xc012237a10?}, 0x0)
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/methods.go:173 +0x785
golang.org/x/tools/go/ssa.(*Program).needMethodsOf(0xc0004b28f0, {0x11c0f70?, 0xc012237a10?})
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/methods.go:145 +0x70
golang.org/x/tools/go/ssa.emitConv(0xc00ba7a000, {0x11c8c58, 0xc00e72eae0}, {0x11c0f48?, 0xc000678e00})
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/emit.go:210 +0x405
golang.org/x/tools/go/ssa.(*builder).stmt(0x0?, 0xc00ba7a000, {0x11c3f70?, 0xc011fffc40?})
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:2054 +0x1fa8
golang.org/x/tools/go/ssa.(*builder).stmtList(0xc00e3fc840?, 0x0?, {0xc011fffc60?, 0x2, 0xc00da7b940?})
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:796 +0x67
golang.org/x/tools/go/ssa.(*builder).stmt(0xc00ba7a000?, 0xc00ba7a000, {0x11c39d0?, 0xc0121004b0?})
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:2111 +0x1391
golang.org/x/tools/go/ssa.(*builder).buildFunction(0xe82080?, 0xc00ba7a000)
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:2204 +0x47a
golang.org/x/tools/go/ssa.(*builder).buildFuncDecl(0xe82080?, 0xc00f4d81e0, 0xc0121004e0)
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:2234 +0x154
golang.org/x/tools/go/ssa.(*Package).build(0xc00f4d81e0)
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:2350 +0xd25
sync.(*Once).doSlow(0xc001be9830?, 0xc001bf1248?)
	/workdir/go/src/sync/once.go:70 +0xc2
sync.(*Once).Do(...)
	/workdir/go/src/sync/once.go:61
golang.org/x/tools/go/ssa.(*Package).Build(...)
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:2269
golang.org/x/tools/go/ssa.(*Program).Build.func1(0x0?)
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:2253 +0x4c
created by golang.org/x/tools/go/ssa.(*Program).Build
	/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.8/go/ssa/builder.go:2252 +0x19c
FAIL	golang.org/x/vulndb/internal/worker	2.942s

greplogs --dashboard -md -l -e 'panic: no concrete method: func \(\*crypto/elliptic\.nistCurve' --since=2022-01-01
2022-04-29T20:16:31-4bd1791-3ce203d/linux-amd64
2022-04-29T20:16:31-4bd1791-3ce203d/linux-amd64-longtest
2022-04-29T18:35:07-4bd1791-8c5917c/linux-amd64
2022-04-29T18:35:07-4bd1791-8c5917c/linux-amd64-longtest
2022-04-29T02:01:27-4bd1791-e7c56fe/linux-amd64
2022-04-29T02:01:27-4bd1791-e7c56fe/linux-amd64-longtest
2022-04-29T01:45:33-4bd1791-a5dd684/linux-amd64
2022-04-29T01:45:33-4bd1791-a5dd684/linux-amd64-longtest
2022-04-29T01:00:55-4bd1791-e7b0559/linux-amd64
2022-04-29T01:00:55-4bd1791-e7b0559/linux-amd64-longtest
2022-04-28T23:35:11-4bd1791-cb6fc99/linux-amd64
2022-04-28T23:35:11-4bd1791-cb6fc99/linux-amd64-longtest
2022-04-28T23:16:44-682b022-cb6fc99/linux-amd64
2022-04-28T23:16:44-682b022-cb6fc99/linux-amd64-longtest
2022-04-28T20:14:34-682b022-c90a19a/linux-amd64
2022-04-28T20:14:34-682b022-c90a19a/linux-amd64-longtest
2022-04-28T20:11:37-682b022-74f0009/linux-amd64
2022-04-28T20:11:37-682b022-74f0009/linux-amd64-longtest
2022-04-28T18:41:25-682b022-96a1ad2/linux-amd64
2022-04-28T18:41:25-682b022-96a1ad2/linux-amd64-longtest
2022-04-28T18:28:44-682b022-123e271/linux-amd64
2022-04-28T18:28:44-682b022-123e271/linux-amd64-longtest
2022-04-28T18:02:40-682b022-c15d0a9/linux-amd64
2022-04-28T18:02:40-682b022-c15d0a9/linux-amd64-longtest
2022-04-28T17:14:41-682b022-4289bd3/linux-amd64
2022-04-28T17:14:41-682b022-4289bd3/linux-amd64-longtest
2022-04-28T16:50:31-682b022-29bbca5/linux-amd64
2022-04-28T16:50:31-682b022-29bbca5/linux-amd64-longtest
2022-04-28T16:29:07-682b022-4bb45f7/linux-amd64
2022-04-28T16:29:07-682b022-4bb45f7/linux-amd64-longtest
2022-04-28T16:00:39-682b022-17371ee/linux-amd64
2022-04-28T16:00:39-682b022-17371ee/linux-amd64-longtest
2022-04-28T15:11:42-682b022-4d35071/linux-amd64
2022-04-28T15:11:42-682b022-4d35071/linux-amd64-longtest
2022-04-27T21:19:21-682b022-89044b6/linux-amd64
2022-04-27T21:19:21-682b022-89044b6/linux-amd64-longtest
2022-04-27T17:24:48-421e78b-89044b6/linux-amd64
2022-04-27T17:24:48-421e78b-89044b6/linux-amd64-longtest
2022-04-27T17:20:34-421e78b-f0ee7fd/linux-amd64-longtest
2022-04-27T15:22:15-421e78b-0b5218c/linux-amd64
2022-04-27T15:22:15-421e78b-0b5218c/linux-amd64-longtest
2022-04-27T14:23:28-421e78b-f0c0e0f/linux-amd64
2022-04-27T14:23:28-421e78b-f0c0e0f/linux-amd64-longtest

(attn @jba; CC @golang/security)

(This is a release-blocker for Go 1.19 via #11811.)

https://go.dev/cl/402674 should fix.

https://build.golang.org/?repo=golang.org%2Fx%2Fvulndb shows the fix is effective, thanks, closing.

authors: bcmills dmitshur jba


text:
x/tools/gopls: enable network usage whenever reinitializing the workspace

This is an umbrella issue for visibility. We plan to change the default gopls behavior to allow network usage whenever "reinitializing" the workspace (which happens whenever a go.mod or go.work file is saved).
Currently, gopls only allows network usage during the initial workspace load. In all subsequent go command invocations, it sets GOPROXY=off. The original rationale for this is #38462, which was reporting poor behavior without internet because gopls uses the go command to compute go mod tidy diagnostics.  To fix this, we set GOPROXY=off while running go mod tidy. However, at the time, any typing in a go.mod file would trigger a reinitialization, so it was decided to also disable network when reinitializing.
But this can lead to a confusing user experience, in part because the GOPROXY=off error message leaks, and in part because this is an example where restarting gopls can lead to a different state (because redo-ing the initial workspace load will allow network and fix problems).
Specifically, we have at least the following open issues:

[ ] #53676, where the "GOPROXY=off" error leaks to the user and it is very confusing (because the user didn't set GOPROXY=off).
[ ] #47540, where gopls cannot recover from a failed initial workspace load

Now that we only reinitialize on a go.work or go.mod file save, reinitialization should be infrequent. We should allow network, so that reinitialization has the same result as the initial workspace load.

This was done by https://go.dev/cl/419500


text:
x/tools/gopls: WorkspaceSymbol returns strange results in strange order

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

$ go version
go version go1.20.2 linux/arm64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.8.1-0.20230424202313-71ea8f168c16
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20230424202313-71ea8f168c16

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE="on"
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.20.2"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build235298812=/tmp/go-build -gno-record-gcc-switches"

What did you do?
cd $(mktemp -d)
git clone https://github.com/mvdan/sh
cd sh
git checkout 1e9de6acbbb76e4387751bda2bba2cbd42a0ee5d
vi syntax/parser.go

Then perform a symbol search for rune, in an attempt to locate the symbol mvdan.cc/sh/v3/syntax.Parser.rune.
The results are ordered as follows (best match first):
mvdan.cc/sh/v3/interp.Runner
mvdan.cc/sh/v3/interp.runnerOpts
mvdan.cc/sh/v3/interp.RunnerOption
mvdan.cc/sh/v3/interp_test.runTest
mvdan.cc/sh/v3/interp_test.runTests
mvdan.cc/sh/v3/interp_test.runnerCtx
mvdan.cc/sh/v3/cmd/gosh.runInteractive
mvdan.cc/sh/v3/interp_test.runTestsUnix
mvdan.cc/sh/v3/interp_test.runTests64bit
mvdan.cc/sh/v3/interp_test.runTestsWindows
mvdan.cc/sh/v3/syntax.Parser.rune
mvdan.cc/sh/v3/syntax.singleRuneParam
mvdan.cc/sh/v3/interp_test.TestRunnerDir
...

I've included ~20% of the results returned. Notice that I performed this search when in the context of the syntax package.
The one row (in the first 20% of results) where there is a full match on the last element (i.e. the symbol itself), the row I actually want, is at position 11. There are less good matches in the first 10 rows, some of which are in test packages. None of those first 10 are in the package of interest (given the current file cursor position in syntax/parser.go).
This problem is related to #37237. That said, https://github.com/golang/go/issues/37236#issuecomment-1536515780 makes clear that there are currently no plans to implement such an approach.
Therefore I think the current matching logic should be better here.
I've not looked at this part of the code recently, but it seems like the scoring of perfect matches for the symbol itself could/should score much higher?
What did you expect to see?
mvdan.cc/sh/v3/syntax.Parser.rune returned as the first result.
What did you see instead?
As above.

gopls.log
govim.log

Thanks, this is a regression that we had not noticed since other clients perform their own sorting.
I'll fix this presently.

Correction, this is not a regression, but rather a poor downranking of nested fields/methods.
The raw matching score for "rune" is 100%, but is downranked to 80% for being a method.
The raw matching score for "Runner" is 90%, and is not downranked as it is a top-level declaration.
I think the downranking for fields/methods is far too high, as it should only be a tie-breaker. I'll reduce it significantly.

authors: findleyr myitcv


text:
path/filepath: Clean on some invalid Windows paths can lose .. components

On Windows:
filepath.Clean("a/../b:/../../c") == "c" // expect "../c"

This is due to a bug in CL 468123, which ensures Clean will not convert a relative path into one starting with a drive reference. (Clean("a/../b:") == "./b:", not "b:".)
An effect of this is that filepath.IsLocal(p) and filepath.IsLocal(filepath.Clean(p)) may be different, with Clean converting a non-local relative path into a local one as in the above example. I don't think this is a vulnerability as such, but it's worth noting.
Thanks to Juho Nurminen of Mattermost for reporting this issue.

@gopherbot please open backport issues. This is a bug with no good workarounds.