text:
Vulkan raytracing plumbing

Here's a bunch of code adding some Vulkan raytracing stuff to the rendering device:

Vulkan implementations in RenderingDeviceDriverVulkan
Raytracing instruction list in RenderingDeviceGraph
Functions to create acceleration structures and raytracing pipelines in RenderingDevice

There's more in the fahien/raytracing-test branch, with code handling raygen, miss, and closest-hit shaders, but it's a hack on top of the forward clustered renderer, and it needs some "guided" refactoring.
I hope this changes would look useful to jump-start raytracing support.
Relevant for https://github.com/godotengine/godot-proposals/discussions/5162

Commits needs to be squashed (see https://docs.godotengine.org/en/latest/contributing/workflow/pr_workflow.html).

I had a very brief look and it looks pretty good to me, although I'd hold off on making changes that add a new rendering method. Are you planning on sticking to only supporting the hit shader workflow or would you also like to add ray query support as well?
If you'd like to test your rendering without adding a new rendering method, keep in mind you can also use GDScript to drive the renderer and it should be pretty sufficient to test it out.

i see that you started on a renderer too on that repo, i think your renderer could be tested/based on the godot ideas
https://gist.github.com/reduz/c5769d0e705d8ab7ac187d63be0099b5

@DarioSamo

I had a very brief look and it looks pretty good to me, although I'd hold off on making changes that add a new rendering method. Are you planning on sticking to only supporting the hit shader workflow or would you also like to add ray query support as well?

Just focusing on the hit shader for now.

If you'd like to test your rendering without adding a new rendering method, keep in mind you can also use GDScript to drive the renderer and it should be pretty sufficient to test it out. This is also a simple way you can provide us with a demo project to test it out.

There you go: https://github.com/Fahien/godot-raytracing-gdscript-demo

@Calinou, thank you for your review and for testing it!

Remember to add a fallback error message for when raytracing isn't supported and any RT function is called (the check should be cached). This cached value should also be queryable from scripts, so that in-game options menus can disable options that won't be able to work on the user's GPU.

Done, also updated the sample project.

I wonder if this should also be exposed as a shader preprocessor define in the long run (for Godot's shader language), so that you can perform different shader compilations depending on support.

Sounds doable.

Unrelated to this PR but, from a CI perspective, it would be nice to run godot.linuxbsd.editor.x86_64 --doctool --headless in an early job (Static checks / Code style, file formatting, and docs), as I only noticed it was failing by looking at the Linux mono job.

That's not possible, it needs a compiled version of the engine

Thanks to @Fahien for making the changes we agreed to. I won't have much time to review this until I get back in a few weeks but I'd like to know if you're willing to extend this PR to cover the other backends or if the intention is only for Vulkan to be merged first.
If you wish to tackle the other APIs, I can leave you some relevant documentation on how to replicate the drivers functionality in the meantime.

@DarioSamo: I'd like to know if you're willing to extend this PR to cover the other backends or if the intention is only for Vulkan to be merged first.

I can try, but I wonder if it would be better doing this in subsequent PRs.

@Calinou: I wonder if this should also be exposed as a shader preprocessor define in the long run (for Godot's shader language), so that you can perform different shader compilations depending on support.

Done

Sorry if I'm a little bit in-experienced, but out of curiosity I pulled the branch and built it, then ran it on the example gdscript project, it was obviously out of date with the latest version of the branch, so I updated the render() function in raytracing.gd with the one found in the raytracing_list_begin description, with the addition of the last two lines actually getting the texture and assigning it to the viewport. Unfortunately this is the result:

Any idea why this is occurring? I assume I missed something but it's not currently throwing any errors.
The full script is here:
extends Node3D

@onready
var rd := RenderingServer.create_local_rendering_device()
@onready
var screen_texture := get_node("TextureRect")

var raytracing_texture: RID
var shader: RID
var raytracing_pipeline: RID
var vertex_buffer: RID
var vertex_array: RID
var index_buffer: RID
var index_array: RID
var transform_buffer: RID
var blas: RID
var tlas: RID
var uniform_set: RID

func _cleanup():
	if rd == null:
		return

	rd.free_rid(uniform_set)
	rd.free_rid(tlas)
	rd.free_rid(blas)
	rd.free_rid(transform_buffer)
	rd.free_rid(index_array)
	rd.free_rid(index_buffer)
	rd.free_rid(vertex_array)
	rd.free_rid(vertex_buffer)
	rd.free_rid(raytracing_pipeline)
	rd.free_rid(shader)
	rd.free_rid(raytracing_texture)
	rd.free()
	rd = null

func _notification(what: int):
	if what == NOTIFICATION_PREDELETE:
		_cleanup()

func _ready():
	if rd.raytracing_is_supported():
		_initialise_screen_texture()
		_initialize_raytracing_texture()
		_initialize_scene()
		_initialize_raytracing_pipeline()

func _process(_delta):
	if rd.raytracing_is_supported():
		_render()

func _initialize_raytracing_texture():
	# Create texture for raytracing rendering.
	var texture_format := RDTextureFormat.new()
	texture_format.texture_type = RenderingDevice.TEXTURE_TYPE_2D
	texture_format.format = RenderingDevice.DATA_FORMAT_R32G32B32A32_SFLOAT
	texture_format.width = get_viewport().size.x
	texture_format.height = get_viewport().size.y
	# It needs storage bit for the raytracing pipeline and can copy from for the presentation graphics pipeline.
	texture_format.usage_bits = RenderingDevice.TEXTURE_USAGE_CAN_COPY_FROM_BIT | RenderingDevice.TEXTURE_USAGE_STORAGE_BIT
	var texture_view := RDTextureView.new()
	raytracing_texture = rd.texture_create(texture_format, texture_view)

func _initialise_screen_texture():
	var image_size = get_viewport().size
	var image = Image.create(image_size.x, image_size.y, false, Image.FORMAT_RGBAF)
	var image_texture = ImageTexture.create_from_image(image)
	screen_texture.texture = image_texture

func _set_screen_texture_data(data: PackedByteArray):
	var image_size = get_viewport().size
	var image := Image.create_from_data(image_size.x, image_size.y, false, Image.FORMAT_RGBAF, data)
	screen_texture.texture.update(image)

func _initialize_raytracing_pipeline():
	# Create raytracing shaders.
	var shader_file := load("res://ray.glsl")
	var shader_spirv: RDShaderSPIRV = shader_file.get_spirv()
	shader = rd.shader_create_from_spirv(shader_spirv)
	raytracing_pipeline = rd.raytracing_pipeline_create(shader)

	var image_uniform := RDUniform.new()
	image_uniform.uniform_type = RenderingDevice.UNIFORM_TYPE_IMAGE
	image_uniform.binding = 0
	image_uniform.add_id(raytracing_texture)

	var as_uniform := RDUniform.new()
	as_uniform.uniform_type = RenderingDevice.UNIFORM_TYPE_ACCELERATION_STRUCTURE
	as_uniform.binding = 1
	as_uniform.add_id(tlas)

	uniform_set = rd.uniform_set_create([image_uniform, as_uniform], shader, 0)

func _initialize_scene():
	# Vertex buffer for a triangle
	# Prepare our data. We use floats in the shader, so we need 32 bit.
	var points := PackedFloat32Array([
			 0.0, -0.7, 1.0,
			 0.5, -0.7, 1.0,
			 0.0,  0.5, 1.0,
			-0.5, -0.7, 1.0,
			 0.5, -0.7, 1.0,
			-0.5,  0.5, 1.0,
		])
	var point_bytes := points.to_byte_array()
	vertex_buffer = rd.vertex_buffer_create(point_bytes.size(), point_bytes, true)
	var vertex_desc := RDVertexAttribute.new()
	vertex_desc.format = RenderingDevice.DATA_FORMAT_R32G32B32_SFLOAT
	vertex_desc.location = 0
	vertex_desc.stride = 4 * 3
	var vertex_format := rd.vertex_format_create([vertex_desc])
	vertex_array = rd.vertex_array_create(points.size() / 3, vertex_format, [vertex_buffer], [3*3*4])

	# Index buffer
	var indices := PackedInt32Array([0, 2, 1])
	var index_bytes := indices.to_byte_array()
	index_buffer = rd.index_buffer_create(indices.size(), RenderingDevice.INDEX_BUFFER_FORMAT_UINT32, index_bytes)
	index_array = rd.index_array_create(index_buffer, 0, indices.size())

	# Transform buffer
	var transform_matrix := PackedFloat32Array([
		1.0, 0.0, 0.0, 0.0,
		0.0, 1.0, 0.0, 0.0,
		0.0, 0.0, 1.0, 0.0,
	])
	var transform_bytes := transform_matrix.to_byte_array()
	transform_buffer = rd.storage_buffer_create(transform_bytes.size(), transform_bytes, RenderingDevice.STORAGE_BUFFER_USAGE_SHADER_DEVICE_ADDRESS | RenderingDevice.STORAGE_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY)

	# Create a BLAS for a mesh
	blas = rd.blas_create(vertex_array, index_array, transform_buffer)
	# Create TLAS with BLASs.
	tlas = rd.tlas_create([blas])

func _render():
	# Build acceleration structures.
	rd.acceleration_structure_build(blas)
	rd.acceleration_structure_build(tlas)

	var raylist = rd.raytracing_list_begin()

	# Bind pipeline and uniforms.
	rd.raytracing_list_bind_raytracing_pipeline(raylist, raytracing_pipeline)
	rd.raytracing_list_bind_uniform_set(raylist, uniform_set, 0)

	# Trace rays.
	var width = get_viewport().size.x
	var height = get_viewport().size.y
	rd.raytracing_list_trace_rays(raylist, width, height)

	rd.raytracing_list_end()

	var byte_data := rd.texture_get_data(raytracing_texture, 0)
	_set_screen_texture_data(byte_data)

authors: AThousandShips Bonkahe Chaosus DarioSamo Fahien octanejohn


text:
META tag errors when submitting invalid logon parameters via SOAP

Hi Guilherme,
I noticed that when passing invalid logon parameters (wrong password, invalid client number, invalid username) using the soap connection, errors are returned in the form of "The META start tag on line X position XX does not match the end of tag of 'head'.." instead of returning meaningful errors e.g. access denied etc. Is it possible to make the library to return meaningful errors re. invalid parameters passed? I also noticed that the NetWeaver actually returned http access denied error to web client instead of passing a proper xml error response, but I haven't gone further on this though to be 100 pct sure. Many thanks and keep up the good work!
Kind regards,
Faizul

I'll look into it as soon as I can. Thanks for your input.

source: gharchive/issue

repo: goenning/SharpSapRfc

license: mit

license_type: permissive

license_source: bigquery


text:
Restructuring psibase macros

This PR restructures the psibase_macros into a 3-project workspace for easier dev/testing.
In addition to the 3-project structure, it also splits service_macro.rs into separate files for better readability/maintainability.
There are a couple of TODOs but only in the test files and are notes for tests I can add; nothing functionally missing from this PR.
All files in the rust/psibase_macros/psibase-macros-lib/src/service_macro/ dir is unmodified code simply spilt out from the single formerly rust/psibase_macros/psibase-macros-lib/src/service_macro.rs into more bite-sized chunks.

You can also add your unit tests to CI/CD in rust/CMakeLists.txt if they belong

Was this addressed?

You can also add your unit tests to CI/CD in rust/CMakeLists.txt if they belong

Was this addressed?

It is now.

source: gharchive/pull-request

authors: cool-ant swatanabe

repo: gofractally/psibase

license: MIT

license_source: github-api


text:
Gatekeeper 2.9.0 can`t pull the image

Hi, can't pull the image docker pull quay.io/gogatekeeper/gatekeeper:2.9.0.
Error response from daemon: manifest for quay.io/gogatekeeper/gatekeeper:2.9.0 not found: manifest unknown: manifest unknown

docker pull quay.io/gogatekeeper/gatekeeper:2.8.1 - pulls out with no problem.

@hillout hi, yes i know quay.io has build service image outage from Friday, don't know when they will fix it, they had Monday on status page, but i still see outage notice https://status.quay.io

@hillout seems quay.io is backup and built 2.9.0 image

repo: gogatekeeper/gatekeeper


text:
gvalid 进行正则 check 的时候会去除字符串空格

之前有反馈过，改过一版。之后好像又改回去了 https://github.com/gogf/gf/issues/781

@jssyjam 哦？！不好意思，有点久了，要不你给个复现问题的代码，我再看看？也许我可以加到单元测试里面去。

authors: gqcn jssyjam

repo: gogf/gf


text:
Html tags not being closed across issue comments

In a previous comment I have <strike>foo bar</strik> (deliberate typo)
Then I save the comment and that strike continues across the design, including comment header details, and the next comment body all the way down the page.
Is there any way broken tags can be sorted? Maybe HTML tidy?

Test foo bar

Looks like GitHub has some tools fix this.

I'm pretty sure github tries to fix bad html. An alternative should be stripping of invalid tags.

Haha, fixed.

authors: ChangePlaces Unknwon tboerger

repo: gogits/gogs


text:
建议对于未登录的用户关闭“发现” 功能

目前太暴露了 ，没有登录的用户直接能看到已注册的用户和组织， 这不科学 不够保密。
我目前只能用服务器屏蔽这两个地址，希望改进。。

配置 REQUIRE_SIGNIN_VIEW = true 要求用户必须登录才能浏览任何页面


text:
Move the --format flag to only the commands that support it (and also reintroduce the -f short)

Reference: https://discourse.gohugo.io/t/44556/2

Also see #11015
I guess adding this as a persistent flag thinking we could add format support to list etc. ... eventually, was a bad idea.

authors: bep jmooring

repo: gohugoio/hugo


text:
Automatically create default Archetype based on config file format

(follow up to #9363)
With hugo new site -f toml name-of-site (or -f json or -f yaml), the format of the configuration file can be changed. Currently, this does not change the format used for frontmatter in new content.
I think it might be a good idea to generate different archetypes/default.md files based on the format selected when creating a new Hugo site.
If you want to make it really customisable, maybe add a --frontmatter-format option to hugo new site so that the frontmatter format can be set independently of the config file format. This would also allow the frontmatter in the default archetype to be in Org Mode format.

I'm quite busy this weekend, but if after that a fix hasn't been submitted I'll look into submitting a PR myself.

I wouldn't spend any time on this:

The majority of sites that I have seen use TOML for config and YAML for front matter.
Creating a new site is an infrequent task.
The effort required to manually change the archetype format after site creation is minimal.
The selection of formats is opinionated. For example, I would never use YAML for front matter, but I might use YAML for a complex site configuration. To some extent this is a tabs/spaces discussion, which is fruitless, because everyone knows spaces are the correct choice.

We're not doing this.

authors: bep jmooring ktprograms


text:
One line code blocks poorly render on Firefox.

While trying to view a code block from Firefox, if the block only contains one line of code it is rendered closer to the line number.
I tried on the quickstart  example this markdown file:
---
title: "My First Post"
date: 2022-01-12T15:47:42+01:00
draft: true
---

## Code block with one line

(this should be a codeblock)
a = [b**2 for b in range(5)]

## Code block with multiple lines

(this should be a codeblock)
a = [b**2 for b in range(5)]
print(a)

with the following config.toml file:
baseURL = "http://example.org/"
languageCode = "en-us"
title = "My New Hugo Site"
theme = "ananke"

[markup]
  [markup.highlight]
  pygmentsUseClasses = true
    anchorLineNos = false
    codeFences = true
    guessSyntax = false
    hl_Lines = ""
    lineAnchors = ""
    lineNoStart = 1
    lineNos = true
    lineNumbersInTable = true

On Chrome and Microsoft Edge everything looks good.

Please use the forum (https://discourse.gohugo.io) for questions and troubleshooting. We prefer to use GitHub for verified bugs and vetted enhancements. Thanks.

Does it work if you add this to the CSS?:
.chroma .lnt {
  display: block;
}

authors: AdorianM BBaoVanC jmooring


text:
"redgood" theme submission

Theme submission
Link to my theme repository: https://github.com/urjaacharya/redgood
I made sure that...

[x] the repository contains a good README.md describing my theme
[x] an open source license has been added to LICENSE.md
[x] all metadata have been added to theme.toml
[x] screenshots have been added in the images/ folder with the required dimensions
[x] in case I'm using a customized demo via the exampleSite folder that

[x] https://example.com is set as base url in exampleSite/config.{toml, yaml, json} to avoid the abuse of unused domains
[x] I tested that my theme's demo works with the content directory of gohugoio/HugoBasicExample

[x] I tested my theme against the gohugoio/HugoBasicExample

[x] I've checked the developer tools' console in my browser for error messages

[ ] in case my theme is using Hugo Pipes features like toCSS and PostCSS that I have committed the /resources directory with all generated assets, for my theme to work in the basic version of Hugo

Link to my Twitter account (optional): https://twitter.com/urja_

@urjaacharya
Thank you for the submission, the theme was added in 2d8db36

@digitalcraftsman
redgood is a clean blog theme without JavaScript.

Thank you @onedrawingperday. The demo does not show the pinned posts or archive. My netlify demo has those things. How can I fix that?

By default demo content is inherited by the hugoBasicExample because in the past we had instances of inappropriate content in a couple of demos.
The above is also mentioned in the repo README.

Thank you  for the theme submission, Urja. Your theme is already live on Hugo's theme site and will be promoted soon on Hugo's official Twitter account.

repo: gohugoio/hugoThemes


text:
Remove the git config

git config --global user.email and user.name from the CI setup.
Omitting it should use the @actions user -- which is better:
https://github.com/marketplace/actions/setup-git-user
/cc @peaceiris

I'll commit this directly to the main branch.

repo: gohugoio/hugoThemesSiteBuilder


text:
Crash opening textview.go - threads

Johns-Mac-Pro:~/go/src/github.com/goki/gi/examples/textview $ ./textview
2018/09/17 08:58:30 KeyMap: key function is nil -- probably renamed, for key: Control+C
2018/09/17 08:58:30 KeyMap: key function is nil -- probably renamed, for key: Control+X
warning - KeyFunNil has no key mappingwarning - KeyFunNil has no key mappingfatal error: concurrent map read and map write
goroutine 11 [running]:
runtime.throw(0x4853774, 0x21)
/usr/local/go/src/runtime/panic.go:616 +0x81 fp=0xc420595338 sp=0xc420595318 pc=0x402da11
runtime.mapaccess1_fast64(0x4723800, 0xc4204a4cc0, 0xc, 0x7)
/usr/local/go/src/runtime/hashmap_fast.go:101 +0x197 fp=0xc420595360 sp=0xc420595338 pc=0x400dcc7
github.com/goki/gi.(*FontLib).Font(0x51d1000, 0xc4252dfad0, 0x7, 0xc, 0x0, 0x0, 0x0, 0x0)
/Users/rohrlich/go/src/github.com/goki/gi/font.go:739 +0x55a fp=0xc420595438 sp=0xc420595360 pc=0x42c99aa
github.com/goki/gi.(*FontStyle).OpenFont(0xc424fd3290, 0xc420198d64)
/Users/rohrlich/go/src/github.com/goki/gi/font.go:357 +0xfd fp=0xc4205954c0 sp=0xc420595438 pc=0x42c81cd
github.com/goki/gi.(*TextRender).SetHTMLPre(0xc420157f00, 0xc424e26bab, 0x1f5, 0x1f5, 0xc422d6fb90, 0xc420198ce0, 0xc420198d64, 0xc42055c360)
/Users/rohrlich/go/src/github.com/goki/gi/text.go:1405 +0x16a7 fp=0xc420595e90 sp=0xc4205954c0 pc=0x4308d07
github.com/goki/gi/giv.(*TextView).HiAllLines(0xc420198a00)
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:448 +0x4fb fp=0xc420595fd8 sp=0xc420595e90 pc=0x45a7d4b
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc420595fe0 sp=0xc420595fd8 pc=0x4059871
created by github.com/goki/gi/giv.(*TextView).LayoutAllLines
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:505 +0x669
goroutine 1 [syscall, locked to thread]:
github.com/goki/gi/oswin/driver/macdriver._Cfunc_startDriver()
_cgo_gotypes.go:682 +0x41
github.com/goki/gi/oswin/driver/macdriver.startDriver()
/Users/rohrlich/go/src/github.com/goki/gi/oswin/driver/macdriver/cocoa.go:102 +0x3b
github.com/goki/gi/oswin/driver/macdriver.Main(0xc42019fe70)
/Users/rohrlich/go/src/github.com/goki/gi/oswin/driver/macdriver/macdriver.go:27 +0x36
github.com/goki/gi/oswin/driver.main(0xc42019fe70)
/Users/rohrlich/go/src/github.com/goki/gi/oswin/driver/driver_darwin.go:20 +0x2b
github.com/goki/gi/oswin/driver.Main(0xc42019fe70)
/Users/rohrlich/go/src/github.com/goki/gi/oswin/driver/driver.go:27 +0x2b
github.com/goki/gi/gimain.Main(0x4890aa0)
/Users/rohrlich/go/src/github.com/goki/gi/gimain/gimain.go:24 +0x5c
main.main()
/Users/rohrlich/go/src/github.com/goki/gi/examples/textview/textview.go:22 +0x2d
goroutine 10 [runnable]:
github.com/goki/gi.(*StyledFields).ToDots(0xc4200ae910, 0x477bc80, 0xc420213138, 0xc42021336c)
/Users/rohrlich/go/src/github.com/goki/gi/style.go:579 +0x100
github.com/goki/gi.(*Style).ToDots(0xc420213138)
/Users/rohrlich/go/src/github.com/goki/gi/style.go:318 +0x51
github.com/goki/gi.(*Style).SetUnitContext(0xc420213138, 0xc4205a8000, 0x0)
/Users/rohrlich/go/src/github.com/goki/gi/style.go:291 +0x102
github.com/goki/gi.(*WidgetBase).Style2DWidget(0xc420213008)
/Users/rohrlich/go/src/github.com/goki/gi/widget.go:163 +0x45a
github.com/goki/gi.(*Layout).StyleLayout(0xc420213008)
/Users/rohrlich/go/src/github.com/goki/gi/layout.go:1711 +0x31
github.com/goki/gi.(*Layout).Style2D(0xc420213008)
/Users/rohrlich/go/src/github.com/goki/gi/layout.go:1719 +0x2b
github.com/goki/gi.(*Node2DBase).Style2DTree.func1(0x49d8640, 0xc420213008, 0x3, 0x47dada0, 0xc4205a8a80, 0xb)
/Users/rohrlich/go/src/github.com/goki/gi/node2d.go:517 +0x51
github.com/goki/ki.(*Node).FuncDownMeFirst(0xc420213008, 0x3, 0x47dada0, 0xc4205a8a80, 0x48900b8, 0x0)
/Users/rohrlich/go/src/github.com/goki/ki/node.go:999 +0x6b
github.com/goki/ki.(*Node).FuncDownMeFirst.func1(0x49d8640, 0xc420213008, 0x3, 0x47dada0, 0xc4205a8a80, 0xc420212c00)
/Users/rohrlich/go/src/github.com/goki/ki/node.go:1004 +0x59
github.com/goki/ki.(*Node).FuncFields(0xc420212c00, 0x3, 0x47dada0, 0xc4205a8a80, 0xc422633460)
/Users/rohrlich/go/src/github.com/goki/ki/node.go:963 +0xe8
github.com/goki/ki.(*Node).FuncDownMeFirst(0xc420212c00, 0x3, 0x47dada0, 0xc4205a8a80, 0x48900b8, 0x0)
/Users/rohrlich/go/src/github.com/goki/ki/node.go:1003 +0xee
github.com/goki/ki.(*Node).FuncDownMeFirst(0xc4205a8e88, 0x2, 0x47dada0, 0xc4205a8a80, 0x48900b8, 0x0)
/Users/rohrlich/go/src/github.com/goki/ki/node.go:1008 +0x15c
github.com/goki/ki.(*Node).FuncDownMeFirst.func1(0x49d8640, 0xc4205a8e88, 0x1, 0x47dada0, 0xc4205a8a80, 0xc4205a8a80)
/Users/rohrlich/go/src/github.com/goki/ki/node.go:1004 +0x59
github.com/goki/ki.(*Node).FuncFields(0xc4205a8a80, 0x1, 0x47dada0, 0xc4205a8a80, 0xc4226335f0)
/Users/rohrlich/go/src/github.com/goki/ki/node.go:963 +0xe8
github.com/goki/ki.(*Node).FuncDownMeFirst(0xc4205a8a80, 0x1, 0x47dada0, 0xc4205a8a80, 0x48900b8, 0x49f6e01)
/Users/rohrlich/go/src/github.com/goki/ki/node.go:1003 +0xee
github.com/goki/gi.(*Node2DBase).Style2DTree(0xc4205a8a80)
/Users/rohrlich/go/src/github.com/goki/gi/node2d.go:512 +0x90
github.com/goki/gi.(*WidgetBase).ReRender2DTree(0xc4205a8a80)
/Users/rohrlich/go/src/github.com/goki/gi/widget.go:387 +0x178
github.com/goki/gi.(*WidgetBase).FullReRenderIfNeeded(0xc4205a8a80, 0x42e3e75)
/Users/rohrlich/go/src/github.com/goki/gi/widget.go:315 +0x98
github.com/goki/gi.(*SplitView).Render2D(0xc4205a8a80)
/Users/rohrlich/go/src/github.com/goki/gi/splitview.go:290 +0x31
github.com/goki/gi.(*Layout).Render2DChildren(0xc42068e000)
/Users/rohrlich/go/src/github.com/goki/gi/layout.go:1258 +0x1c1
github.com/goki/gi.(*Frame).Render2D(0xc42068e000)
/Users/rohrlich/go/src/github.com/goki/gi/frame.go:149 +0xc1
github.com/goki/gi.(*Layout).Render2DChildren(0xc420458a00)
/Users/rohrlich/go/src/github.com/goki/gi/layout.go:1258 +0x1c1
github.com/goki/gi.(*Layout).Render2D(0xc420458a00)
/Users/rohrlich/go/src/github.com/goki/gi/layout.go:1796 +0xaf
github.com/goki/gi.(*Node2DBase).Render2DChildren(0xc4205a8000)
/Users/rohrlich/go/src/github.com/goki/gi/node2d.go:628 +0x8e
github.com/goki/gi.(*Viewport2D).Render2D(0xc4205a8000)
/Users/rohrlich/go/src/github.com/goki/gi/viewport2d.go:436 +0x6a
github.com/goki/gi.(*Node2DBase).Render2DTree(0xc4205a8000)
/Users/rohrlich/go/src/github.com/goki/gi/node2d.go:589 +0x90
github.com/goki/gi.(*Node2DBase).FullRender2DTree(0xc4205a8000)
/Users/rohrlich/go/src/github.com/goki/gi/node2d.go:481 +0x89
github.com/goki/gi.(*Viewport2D).FullRender2DTree(0xc4205a8000)
/Users/rohrlich/go/src/github.com/goki/gi/viewport2d.go:373 +0x90
github.com/goki/gi.(*Window).FullReRender(0xc4201a2000)
/Users/rohrlich/go/src/github.com/goki/gi/window.go:592 +0x4f
github.com/goki/gi.(*Window).Resized(0xc4201a2000, 0x6d2, 0x4ed)
/Users/rohrlich/go/src/github.com/goki/gi/window.go:452 +0x1a9
github.com/goki/gi.(*Window).EventLoop(0xc4201a2000)
/Users/rohrlich/go/src/github.com/goki/gi/window.go:1004 +0x21ae
github.com/goki/gi.(*Window).StartEventLoop(0xc4201a2000)
/Users/rohrlich/go/src/github.com/goki/gi/window.go:521 +0x32
main.mainrun()
/Users/rohrlich/go/src/github.com/goki/gi/examples/textview/textview.go:118 +0x15c6
main.main.func1()
/Users/rohrlich/go/src/github.com/goki/gi/examples/textview/textview.go:23 +0x20
github.com/goki/gi/gimain.Main.func1(0x49ac300, 0x51ac6c0)
/Users/rohrlich/go/src/github.com/goki/gi/gimain/gimain.go:25 +0x24
github.com/goki/gi/oswin/driver/macdriver.driverStarted.func1()
/Users/rohrlich/go/src/github.com/goki/gi/oswin/driver/macdriver/cocoa.go:172 +0x40
created by github.com/goki/gi/oswin/driver/macdriver.driverStarted
/Users/rohrlich/go/src/github.com/goki/gi/oswin/driver/macdriver/cocoa.go:171 +0x60
goroutine 23 [select, locked to thread]:
github.com/goki/gi/oswin/driver/macdriver.drawLoop(0xc4204c8900, 0x1)
/Users/rohrlich/go/src/github.com/goki/gi/oswin/driver/macdriver/cocoa.go:220 +0x223
created by github.com/goki/gi/oswin/driver/macdriver.preparedOpenGL
/Users/rohrlich/go/src/github.com/goki/gi/oswin/driver/macdriver/cocoa.go:162 +0xfa
goroutine 12 [runnable]:
strings.lastIndexFunc(0x480cf09, 0x7, 0x48910c0, 0x4891000, 0x0)
/usr/local/go/src/strings/strings.go:733 +0xb1
strings.TrimRightFunc(0x480cf09, 0x7, 0x48910c0, 0x480cf09, 0x7)
/usr/local/go/src/strings/strings.go:690 +0x48
strings.TrimFunc(0x480cf09, 0x7, 0x48910c0, 0x1, 0x1)
/usr/local/go/src/strings/strings.go:703 +0x61
strings.TrimSpace(0x480cf09, 0x7, 0x4802fe3, 0x1)
/usr/local/go/src/strings/strings.go:814 +0x41
github.com/goki/gi.FontFaceName(0x480cf09, 0x7, 0x0, 0x0, 0x1000000000004, 0x4ae0)
/Users/rohrlich/go/src/github.com/goki/gi/font.go:253 +0x7ea
github.com/goki/gi.(*FontStyle).FaceNm(0xc422d0dc20, 0xc420516400, 0x40d9879)
/Users/rohrlich/go/src/github.com/goki/gi/font.go:240 +0x4d
github.com/goki/gi.(*FontStyle).OpenFont(0xc422d0dc20, 0xc420680364)
/Users/rohrlich/go/src/github.com/goki/gi/font.go:348 +0x35
github.com/goki/gi.(*TextRender).SetHTMLPre(0xc42015a3c0, 0xc42510789e, 0xf0, 0xf0, 0xc422d0dc20, 0xc4206802e0, 0xc420680364, 0xc420b440c0)
/Users/rohrlich/go/src/github.com/goki/gi/text.go:1273 +0x21c
github.com/goki/gi/giv.(*TextView).HiAllLines(0xc420680000)
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:448 +0x4fb
created by github.com/goki/gi/giv.(*TextView).LayoutAllLines
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:505 +0x669
goroutine 13 [semacquire]:
sync.runtime_SemacquireMutex(0xc420198fb4, 0xc4209d6e00)
/usr/local/go/src/runtime/sema.go:71 +0x3d
sync.(*Mutex).Lock(0xc420198fb0)
/usr/local/go/src/sync/mutex.go:134 +0x108
github.com/goki/gi/giv.(*TextView).HiAllLines(0xc420198a00)
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:438 +0x2bd
created by github.com/goki/gi/giv.(*TextView).LayoutAllLines
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:505 +0x669
goroutine 14 [semacquire]:
sync.runtime_SemacquireMutex(0xc4206805b4, 0xc422309e00)
/usr/local/go/src/runtime/sema.go:71 +0x3d
sync.(*Mutex).Lock(0xc4206805b0)
/usr/local/go/src/sync/mutex.go:134 +0x108
github.com/goki/gi/giv.(*TextView).HiAllLines(0xc420680000)
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:438 +0x2bd
created by github.com/goki/gi/giv.(*TextView).LayoutAllLines
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:505 +0x669
goroutine 15 [semacquire]:
sync.runtime_SemacquireMutex(0xc420198fb4, 0xc422305e00)
/usr/local/go/src/runtime/sema.go:71 +0x3d
sync.(*Mutex).Lock(0xc420198fb0)
/usr/local/go/src/sync/mutex.go:134 +0x108
github.com/goki/gi/giv.(*TextView).HiAllLines(0xc420198a00)
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:438 +0x2bd
created by github.com/goki/gi/giv.(*TextView).LayoutAllLines
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:505 +0x669
goroutine 16 [runnable]:
github.com/dlclark/regexp2/syntax.(*BmPrefix).IsMatch(0xc420a86070, 0xc424ece76c, 0x16c, 0x225, 0x0, 0x0, 0x16c, 0x43ba500)
/Users/rohrlich/go/src/github.com/dlclark/regexp2/syntax/prefix.go:747 +0x115
github.com/dlclark/regexp2.(*runner).findFirstChar(0xc420524800, 0x1)
/Users/rohrlich/go/src/github.com/dlclark/regexp2/runner.go:1287 +0x137
github.com/dlclark/regexp2.(*runner).scan(0xc420524800, 0xc424ece76c, 0x16c, 0x225, 0x0, 0x0, 0x7fffffffffffffff, 0x0, 0x0, 0x0)
/Users/rohrlich/go/src/github.com/dlclark/regexp2/runner.go:130 +0x12a
github.com/dlclark/regexp2.(*Regexp).run(0xc42050c500, 0x0, 0xffffffffffffffff, 0xc424ece76c, 0x16c, 0x225, 0x0, 0x0, 0x0)
/Users/rohrlich/go/src/github.com/dlclark/regexp2/runner.go:91 +0xf2
github.com/dlclark/regexp2.(*Regexp).FindRunesMatch(0xc42050c500, 0xc424ece76c, 0x16c, 0x225, 0x0, 0x0, 0x0)
/Users/rohrlich/go/src/github.com/dlclark/regexp2/regexp.go:163 +0x57
github.com/alecthomas/chroma.matchRules(0xc424ece76c, 0x16c, 0x225, 0xc42031ba00, 0x1a, 0x20, 0xc4258183f0, 0xc4203f98b0, 0xc4258183e0, 0x1, ...)
/Users/rohrlich/go/src/github.com/alecthomas/chroma/regexp.go:399 +0x9a
github.com/alecthomas/chroma.(*LexerState).Iterator(0xc424eee000, 0xc4258207e0)
/Users/rohrlich/go/src/github.com/alecthomas/chroma/regexp.go:270 +0x343
github.com/alecthomas/chroma.(*LexerState).Iterator-fm(0xc4258207e0)
/Users/rohrlich/go/src/github.com/alecthomas/chroma/regexp.go:394 +0x2a
github.com/alecthomas/chroma.(*coalescer).Tokenise.func1(0xc4258207a0)
/Users/rohrlich/go/src/github.com/alecthomas/chroma/coalesce.go:15 +0x3b
github.com/alecthomas/chroma.Iterator.Tokens(0xc424ef4000, 0x488ff60, 0xc424ec5eb8, 0x1347)
/Users/rohrlich/go/src/github.com/alecthomas/chroma/iterator.go:13 +0x5f
github.com/alecthomas/chroma/formatters/html.(*Formatter).Format(0xc420aa1720, 0x4983540, 0xc4201a0070, 0xc42027e520, 0xc424ef4000, 0x0, 0x0)
/Users/rohrlich/go/src/github.com/alecthomas/chroma/formatters/html/html.go:95 +0x67
github.com/goki/gi/giv.(*TextView).HiAllLines(0xc420680000)
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:426 +0x11e
created by github.com/goki/gi/giv.(*TextView).LayoutAllLines
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:505 +0x669

To be clear I was running textview.go and opening textview.go but you can crash opening other files. Here I ran textview.go and was opening textfield.go. The crash doesn't happen every time.
Johns-Mac-Pro:~/go/src/github.com/goki/gi/examples/textview $ ./textview
2018/09/17 09:04:27 KeyMap: key function is nil -- probably renamed, for key: Control+X
2018/09/17 09:04:27 KeyMap: key function is nil -- probably renamed, for key: Control+C
warning - KeyFunNil has no key mappingwarning - KeyFunNil has no key mappingJohns-Mac-Pro:~/go/src/github.com/goki/gi/examples/textview $ ./textview
2018/09/17 09:04:40 KeyMap: key function is nil -- probably renamed, for key: Control+X
2018/09/17 09:04:40 KeyMap: key function is nil -- probably renamed, for key: Control+C
warning - KeyFunNil has no key mappingwarning - KeyFunNil has no key mappingpanic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x42c8524]
goroutine 131 [running]:
github.com/goki/gi.(*FontStyle).ComputeMetrics(0xc42018ec58, 0xc42018ed64)
/Users/rohrlich/go/src/github.com/goki/gi/font.go:384 +0xe4
github.com/goki/gi.(*FontStyle).OpenFont(0xc42018ec58, 0xc42018ed64)
/Users/rohrlich/go/src/github.com/goki/gi/font.go:367 +0x18e
github.com/goki/gi.(*TextRender).LayoutStdLR(0xc420a99b40, 0xc42018ece0, 0xc42018ec58, 0xc42018ed64, 0x4498300044484d00, 0x0)
/Users/rohrlich/go/src/github.com/goki/gi/text.go:1778 +0xc2
github.com/goki/gi/giv.(*TextView).HiAllLines(0xc42018ea00)
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:449 +0x321
created by github.com/goki/gi/giv.(*TextView).LayoutAllLines
/Users/rohrlich/go/src/github.com/goki/gi/giv/textview.go:505 +0x669
Johns-Mac-Pro:~/go/src/github.com/goki/gi/examples/textview $

this is from doing highlighting in a separate task.  Was working reliably for me, after I thought I caught all the crash points.. :)  anyway, other fixes mean this happens much less often now so I'll revert this back to non-parallel which will definitely be more robust..

authors: rcoreilly rohrlich

repo: goki/gi


text:
incorrect description Doc of Gopkg.toml about version

Note: When you specify a version without an operator, dep automatically uses the ^ operator by default. dep ensure will interpret the given version as the min-boundary of a range, for example:
1.2.3 becomes the range >=1.2.3, <2.0.0
interpret the given version as the min-boundary of a range will be ~1.2.3 rather than ^1.2.3
0.2.3 becomes the range >=0.2.3, <0.3.0
0.0.3 becomes the range >=0.0.3, <0.1.0

i'm not sure what this issue is saying - that appears to be a chopped-up copy/paste of what's in the docs. And those docs are accurate.
If you have a correction to make to the docs, you can just go ahead and file a PR, and we can look at whether the suggested change is correct or not.

authors: sdboyer yongliwizard

repo: golang/dep


text:
Go searches for fmt package in pkg folder instead of source

I downloaded and built go from go1.4.2 tar file in my home folder. When I try to run any go file which requires fmt and other default packages of go, it searches in go/src/pkg/  instead of go/src. Can someone please tell me how to resolve this?

Please bring this to the golang-nuts@ mailing list. We only use our issue tracker for bugs.

authors: bradfitz elitalobo

repo: golang/go


text:
Compiler blows up at a switch on a struct initialization.

This works nicely: http://play.golang.org/p/DgB7G3g0LB
OTOH this blows up: http://play.golang.org/p/Z_ceHAaOU2
prog.go:10: syntax error: unexpected name, expecting case or default or }
Is this by design? Seems weird to not be able to instantiate a struct in a switch statement.

Expected. You need to use parens in that second case: http://play.golang.org/p/kSr7pUhV7i
Let's move discussion to one of the forums (https://golang.org/wiki/Questions), though, as there's no bug to track here.

authors: bradfitz zyzniewski-filip


text:
hash/crc32: add more use of Castagnoli's polynomial

Currently the documentation of the Castagnoli variable says that it is used by iSCSI.
However it is also used in SCTP, Btrfs, ext4 and Ceph, as listed on
https://en.wikipedia.org/wiki/Cyclic_redundancy_check
I suggest to add SCTP to the list of standards using CRC32-c.

The list is not really supposed to be exhaustive, and in the end listing some names won't help a reader that doesn't already know what we're talking about. Let's close this.

authors: ALTree perillo


text:
reflect: wrong struct field names for embedded byte, rune

Inspired by discussion on #17746, https://play.golang.org/p/X3OBse1q8_
package main

import "fmt"

type T struct {
	byte
	uint8
	int
	int32
	rune
}

func main() {
	t := T{byte: 1, uint8: 2, int: 3, int32: 4, rune: 5}
	println(t.byte, t.uint8, t.int, t.int32, t.rune)
	fmt.Printf("%#v\n", t)
}

Prints:
1 2 3 4 5
main.T{uint8:0x1, uint8:0x2, int:3, int32:4, int32:5}

The second print should be fixed. It's always been this way, though, so it can and should wait until Go 1.9.
/cc @mdempsky @griesemer @alandonovan @mpvl

This is a bug in the way the gc compiler selects field names, not a bug in reflect.
ssadump -run on this program produces the correct output:
1 2 3 4 5
main.T{byte:0x1, uint8:0x2, int:3, int32:4, rune:5}

cc: @griesemer

authors: alandonovan griesemer rsc


text:
net/smtp: SMTP injection via recipient addresses

(I contacted security@golang.org about this and was asked to create a public issue.)
What version of Go are you using (go version)?
1.8.3 and 1.9beta2
What operating system and processor architecture are you using (go env)?
darwin/amd64
What did you do?
Go's net/smtp package appears to be vulnerable to SMTP injection via recipient e-mail addresses, similar to the issues outlined in this whitepaper for other languages: http://www.mbsd.jp/Whitepaper/smtpi.pdf
Here's a quick demonstration:
package main

import (
	"log"
	"net/smtp"
)

func main() {
	to := []string{"recipient@example.net>\r\nDATA\r\nInjected message body\r\n.\r\nQUIT\r\n"}
	msg := []byte("To: recipient@example.net\r\n" +
		"Subject: discount Gophers!\r\n" +
		"\r\n" +
		"Real message body\r\n")
	err := smtp.SendMail("localhost:25", nil, "sender@example.org", to, msg)
	if err != nil {
		log.Fatal(err)
	}
}

Basically, if you pass an unsanitized address to address inputs, like SendMail, Rcpt, or Mail (eg "recipient@example.net>\r\nDATA\r\nInjected message body\r\n.\r\nQUIT\r\n"), it's possible to manipulate the e-mail body sent.
What did you expect to see?
In the example above, net/smtp should reject the recipient address since it contains line breaks.
What did you see instead?
The message is sent to recipient@example.net with a message body of  "Injected message body" (instead of the intended body of "Real message body").
Notes
As indicated in the whitepaper, the solution for this is to disallow line breaks in the "RCPT TO" and "MAIL FROM" commands, which is also in accordance with RFC 5321. So unless you think it's the responsibility of applications to sanitize addresses (rather than in net/smtp's purview), it would be nice to see this fixed in Go's builtin net/smtp package, so things are safer by default.
If you'd like for me to put together a patch to address this, I'd be happy to try and do that.
And if it helps (and for additional context), you can see how this security issue was addressed in the Ruby ecosystem last year:

Ruby's Net::SMTP library was updated to reject any command lines with line breaks in it.
The "mail" gem was also updated with similar validations, as well as rejecting any addresses longer than 2KB in length.

The length restriction is to address the theoretical CRLF-less attack outlined in the whitepaper, but as the whitepaper's conclusion indicates:

Of course, a little more relaxed rule can be an option, as a small proportion of existing and actually used addresses is known to be incompliant to the standard. Needless to say, when a relaxed rule is employed, addresses containing line-breaks must not be allowed.

So I'm not 100% sure about the best approach, but it seems like perhaps just rejecting line breaks in a library like net/smtp might be preferable, unless you think it's also worth enforcing the line length limits in accordance with RFC 5321.

I just reproduced this and am happy to work on a fix if desired.

A patch for this is welcome.  Thanks.

authors: GUI ggriffiths ianlancetaylor


text:
database/sql: Conn's doc has a typo saying "rather a pool" instead of "rather than a pool"

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
Go1.9
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
Not Applicable
What did you do?
Visited https://golang.org/pkg/database/sql/#Conn to read the docs for Conn
What did you expect to see?
Conn represents a single database session rather than a pool of database sessions.
What did you see instead?
Conn represents a single database session rather than a pool of database sessions.

Just requires us to add than after rather

I try to fix this.

authors: dvrkps odeke-em


text:
gccgo: ICE on invalid pointer embedding

I get go1: internal compiler error: in bind_field_or_method, at go/gofrontend/types.cc:11876 compiling this (invalid) source file with gccgo:
package p

type s *struct{ C int }
type t struct{ *s }

func f(p *t) int {
        return p.C
}

It should produce an error that embedding s into t is invalid because s is a pointer type.
/cc @ianlancetaylor

CC @thanm @cherrymui

I'll take a look tomorrow morning...

Tentative fix mailed. Error messages are as usual slightly different from the main Go compiler:
./bug22050.go:7:10: error: type has no field ‘C’
return p.C
^
./bug22050.go:4:16: error: embedded type may not be a pointer
type t struct{ *s }
^

authors: ianlancetaylor mdempsky thanm


text:
runtime: CallersFrames showing mangled package path for nonASCII pkg name

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go tip:
go version devel +16687a3bbf Fri Sep 14 12:39:54 2018 +0000 linux/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
linux/amd64
What did you do?
In your $GOPATH, unpack the attached tar file: tarfile.gz which will create two subdirs ' Äfoo' and 'Äbar. Change directory to the second and do 'go run':
$ tar zxvf - < tarfile.gz
./Äbar/
./Äbar/Äbar.go
./Äfoo/
./Äfoo/Äfoo.go
$ cd Äbar
$ go run .
- more:true | runtime.Callers
- more:true | %c3%84foo.PrintTrace
- more:true | %c3%84foo.Äblix
- more:true | %c3%84foo.Äbar
- more:true | main.main
- more:true | runtime.main
- more:false | runtime.goexit
Äfoo.Äbar(33) returns 134
$

Note that in the output from runtime.CallersFrames the functions in package Äbar are shown with packagepath in  mangled form (e.g. %c3%84foo.Äblix) instead of regular form (Äbar.Äblix).
What did you expect to see?
Correct package path Äbar.Äblix in callersframe output
What did you see instead?
Mangled package path %c3%84foo
Note: not sure if this is a real bug, pilot error on my part, or if this is WAI. Please close out if appropriate. Also not sure (assuming there is a bug) if this is a compiler issue or a runtime issue (could be that the runtime is simply spitting out whatever the compiler told it.  Thanks -NM.

@aclements @RLH @randall77

authors: andybons thanm


text:
crypto/x509: Go does not load root CA from System keychain on macOS

Disclaimer: I'm new to Go, so please excuse my general lack of knowledge.
The issue I'm experiencing seems to be related to and/or the same as https://github.com/golang/go/issues/14514. It may be related to https://github.com/golang/go/issues/24652 and/or https://github.com/golang/go/issues/27958, but I'm not sure.
My company uses an internal root CA that is installed into the System keychain on my work Mac. All the browsers on my system trust this root correctly, and I have no trouble connecting to internal sites with certificates signed by this root.
I'm working on a Go program that needs to connect to an API that's served with a certificate signed by this internal root CA. I'm not doing anything fancy to configure my HTTP client:
client := &http.Client{Timeout: time.Second * 10}

When I try to make a request to the API, I get the following error: x509: certificate signed by unknown authority.
All the issues I could find that seem to be similar to what I'm experiencing are closed, but the issue is clearly still present. I did find some links to the go-rootcerts package, which does solve the problem when I configure my client like this:
tlsConfig := &tls.Config{}
rootcerts.ConfigureTLS(tlsConfig, &rootcerts.Config{})
transport := &http.Transport{TLSClientConfig: tlsConfig}
client := &http.Client{Timeout: time.Second * 10, Transport: transport}

Obviously, having to include this just so I can develop locally is not ideal.
I have tried opening the certificate in Keychain Access and toggling the trust settings as suggested in this comment, but that didn't change anything.
What version of Go are you using (go version)?
go version go1.11.1 darwin/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
macOS 10.13.6
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/arothman/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/arothman/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.1/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
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/qv/sgn2l7z54zl46vgwrg7qbsp80000gp/T/go-build126370609=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Sorry for the lack of runnable program, but I don't think it would be helpful as the issue is somewhat specific to my system/environment.

Create a basic net/http client.
Attempt a request to an API secured by a certificate signed by a root CA in the machine's System keychain.
😭

What did you expect to see?
Successful request/response.
What did you see instead?
x509: certificate signed by unknown authority

Could you run and paste the output (I expect the command to fail and print) from the command here?  https://github.com/golang/go/issues/24652#issuecomment-411069915

Certainly. Note that Secops Internal Root CA is the certificate in question here.
crypto/x509: kSecTrustSettingsResultInvalid = 0
crypto/x509: kSecTrustSettingsResultTrustRoot = 1
crypto/x509: kSecTrustSettingsResultTrustAsRoot = 2
crypto/x509: kSecTrustSettingsResultDeny = 3
crypto/x509: kSecTrustSettingsResultUnspecified = 4
crypto/x509: Secops Internal Root CA returned 1
crypto/x509: verify-cert rejected CN=com.apple.systemdefault,O=System Identity: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=com.apple.kerberos.kdc,O=System Identity: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=638948197133458968,O=Meraki Inc.,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert approved CN=radius.meraki.com,OU=Domain Control Validated+OU=EssentialSSL
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: verify-cert approved CN=Secops Internal Root CA
crypto/x509: verify-cert rejected CN=SCEP WiFi Certificate for 638948197133458968,ST=California,C=US: "Cert Verify Result: CSSMERR_TP_NOT_TRUSTED"
crypto/x509: ran security verify-cert 15 times
    cgo sys roots: 110.760832ms
non-cgo sys roots: 175.697789ms
certificate only present in non-cgo pool: CN=radius.meraki.com,OU=Domain Control Validated+OU=EssentialSSL (verify error: x509: certificate signed by unknown authority)
signed certificate only present in non-cgo pool (acceptable): CN=Developer ID Certification Authority,OU=Apple Certification Authority,O=Apple Inc.,C=US
SecTrustSettingsCopyCertificates: No Trust Settings were found.
Number of trusted certs = 1
Cert 0: Secops Internal Root CA
   Number of trust settings : 0

!!! The test failed!

/cc @FiloSottile

Hi, maybe related to both this issue and #27958. I try to access an internal server which uses a certificate signed with an intermediate cert. I completely trust the internal root CA and browsers and curl are fine with this. The server in question ships the intermediate together with it‘s own cert. Now http.Client chokes with above error and I have to add the intermediate to the System.keychain and additionally set trust for ssl connections on the intermediate certificate.

authors: adamdecaf adamrothman dmitshur mfriedenhagen


text:
x/image/tiff: panic on Encode for CCITTGroup4 compression

What version of Go are you using (go version)?
go version go1.13.3 darwin/amd64
Does this issue reproduce with the latest release?
Yes, latest master of x/image
What operating system and processor architecture are you using (go env)?
Darwin/amd64
What did you do?
	fo, err := os.Create("output.tiff")
	if err != nil {
		log.Fatal(err)
	}
	defer fo.Close()
	if err := tiff.Encode(fo, img, &tiff.Options{
		Compression: tiff.CCITTGroup4,
	}); err != nil {
		log.Fatal(err)
	}

What did you expect to see?
TIFF written using CCITTGroup4 compression (or optionally an error if compression isn't support for encode).
What did you see instead?
Panic
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x10df6ff]

goroutine 1 [running]:
golang.org/x/image/tiff.writePix(0x0, 0x0, 0xc0000dc000, 0x212c830, 0x212c830, 0xdb4, 0x26bc, 0x26bc, 0xc0000c7b88, 0x100be08)
	/Users/samuel/go/src/golang.org/x/image/tiff/writer.go:211 +0x4f
golang.org/x/image/tiff.encodeRGBA(0x0, 0x0, 0xc0000dc000, 0x212c830, 0x212c830, 0x9af, 0xdb4, 0x26bc, 0xc0000c7c00, 0x1029da1, ...)
	/Users/samuel/go/src/golang.org/x/image/tiff/writer.go:108 +0x2fb
golang.org/x/image/tiff.Encode(0x114db80, 0xc00000e080, 0x114eb80, 0xc002230000, 0xc0000c7e50, 0x1, 0x1)
	/Users/samuel/go/src/golang.org/x/image/tiff/writer.go:378 +0x1391
main.main()
	/Users/samuel/go/src/github.com/samuel/batchimg/main.go:49 +0x661

When Encode sets up the output writer dst for the selected compression it only looks for cNone and cDeflate. Any other choice leads to dst being left nil which means when the encode* functions to to write to it they panic. https://github.com/golang/image/blob/master/tiff/writer.go#L317
Seems best if Encode returned an error in the case of an unsupported compression.

I see that there's a CL (https://go-review.googlesource.com/c/image/+/183224) for adding encoding support in image/ccitt which I assume will also tie into image/tiff so I'll close this since it'll be solved by that. Sorry for the noise.


text:
cmd/go: error isn't properly reported when running go list on cgo package with missing pkg-config

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

$ go version
go version go1.13.3 darwin/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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/muir/Library/Caches/go-build"
GOENV="/Users/muir/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/muir/projects//go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/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/_q/1xpb0k992ll803xsldpx0qyr0000gn/T/go-build252385107=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
I opened a non-cgo package in our project. The package does not transitively depend on any cgo packages.
What did you expect to see?
I expected gopls to load the package with no issue.
What did you see instead?
gopls failed to create the view due to a go list "missing pkg-config" error.
LSP :: Error loading workspace folders (expected 1, got 0)
failed to load view for file:///Users/muir/projects/<project>/go/src: error loading packages: go [list -e -json -compiled=true -test=true -export=false -deps=true -find=false -- ./...]: exit status 2: # pkg-config --cflags  -- <bunch of libraries>
pkg-config: exec: "pkg-config": executable file not found in $PATH

Elsewhere, our project has a cgo package that uses the cgo pkg-config directive (e.g. // #cgo pkg-config: some-library). My laptop doesn't currently have pkg-config installed.
I assume the error comes from the go list ./... we do now when creating a view.

Thanks for reporting. This should probably be handled more gracefully in go/packages. Assigning to @matloob.

I can reproduce the underlying go list issue with the following layout:
foo/go.mod:
module foo

go1.13

foo/foo.go:
package foo

// #cgo pkg-config: bar
import "C"

output of go list -json -compiled . in directory foo:
{
	"Dir": "/Users/matloob/Desktop/foo",
	"ImportPath": "foo",
	"Name": "foo",
	"Root": "/Users/matloob/Desktop/foo",
	"Module": {
		"Path": "foo",
		"Main": true,
		"Dir": "/Users/matloob/Desktop/foo",
		"GoMod": "/Users/matloob/Desktop/foo/go.mod",
		"GoVersion": "1.13"
	},
	"Match": [
		"."
	],
	"Stale": true,
	"StaleReason": "build ID mismatch",
	"CgoFiles": [
		"foo.go"
	],
	"CgoPkgConfig": [
		"bar"
	],
	"Imports": [
		"C",
		"unsafe",
		"runtime/cgo",
		"syscall"
	],
	"Deps": [
		"errors",
		"internal/bytealg",
		"internal/cpu",
		"internal/oserror",
		"internal/race",
		"internal/reflectlite",
		"runtime",
		"runtime/cgo",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"sync",
		"sync/atomic",
		"syscall",
		"unsafe"
	]
}

I'm going to send a cl to suppress the error in go/packages. There are still two problems in go list. The first is that -e isn't being respected. The second is that no error is being generated in the package output by go list.

I'm going to repurpose this bug to fix the issue in go list.
Note that even when the issue is  fixed in go list, if go/packages or gopls are operating on a project that has a dependency on a cgo package that cgo can't successfully be run on, they won't have access to the full set of sources (which need to be generated by cgo). So they might still have problems for those projects.
Of course if none of the packages you're working on have a dependency on the offending package, things should work.

Also note that even after installing pkg-config, go/packages still failed in a similar way because the C library wasn't installed.

What was the error it failed with? we're probably going to have to put another special case in go/packages to ignore that error...

2019/12/06 11:16:40 failed to load snapshot: go [list -e -json -compiled=true -test=true -export=false -deps=true -find=false -- ./...]: exit status 2: # pkg-config --cflags  -- libavdevice libavformat libavfilter libavcodec libswscale libavutil libavdevice libavformat libavfilter libavcodec libswscale libavutil libavdevice libavformat libavfilter libavcodec libswscale libavutil libavdevice libavformat libavfilter libavcodec libswscale libavutil
Package libavdevice was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavdevice.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavdevice' found
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavfilter was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavfilter.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavfilter' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
Package libavdevice was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavdevice.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavdevice' found
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavfilter was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavfilter.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavfilter' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
Package libavdevice was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavdevice.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavdevice' found
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavfilter was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavfilter.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavfilter' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
Package libavdevice was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavdevice.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavdevice' found
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavfilter was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavfilter.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavfilter' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
pkg-config: exit status 1
# pkg-config --cflags  -- libavdevice libavformat libavfilter libavcodec libswscale libavutil libavdevice libavformat libavfilter libavcodec libswscale libavutil libavdevice libavformat libavfilter libavcodec libswscale libavutil libavdevice libavformat libavfilter libavcodec libswscale libavutil
Package libavdevice was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavdevice.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavdevice' found
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavfilter was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavfilter.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavfilter' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
Package libavdevice was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavdevice.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavdevice' found
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavfilter was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavfilter.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavfilter' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
Package libavdevice was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavdevice.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavdevice' found
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavfilter was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavfilter.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavfilter' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
Package libavdevice was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavdevice.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavdevice' found
Package libavformat was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavformat.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavformat' found
Package libavfilter was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavfilter.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavfilter' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavcodec' found
Package libswscale was not found in the pkg-config search path.
Perhaps you should add the directory containing `libswscale.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libswscale' found
Package libavutil was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavutil.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavutil' found
pkg-config: exit status 1

	directory = file:///Users/muir/projects/<project>/go/src
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x16a69d5]

goroutine 136 [running]:
golang.org/x/tools/internal/lsp/cache.(*snapshot).View(0x0, 0xc00018cd80, 0xc0000ce300)
	/Users/muir/projects/tools/internal/lsp/cache/snapshot.go:61 +0x5
golang.org/x/tools/internal/lsp.(*Server).diagnoseSnapshot(0xc000278f60, 0x19cc4c0, 0x0)
	/Users/muir/projects/tools/internal/lsp/diagnostics.go:20 +0x69
created by golang.org/x/tools/internal/lsp.(*Server).addFolders
	/Users/muir/projects/tools/internal/lsp/general.go:173 +0x600

I'm abandoning the change. We've decided that the cost of the change is greater than the benefit. Because it's impossible to determine which package the error belongs to, we'd have to drop the error (or add errors to all packages) to work around it.
In general it's hard for go/packages to work correctly for code that doesn't build.

When "go list" produces the cgo error and exits uncleanly it still also dumps what seems to be the normal JSON results (minus the cgo generated files). What would happen if we ignored the error and continued using the results?
If that is not tenable, is there some way we can at least make gopls able to start in the case of unbuildable cgo package?

Did CL 209420 help with this at all, or does gopls still fail in this case? If it does, I can add some workarounds in gopls to handle it.

I uninstalled ffmpeg and still got the above panic (on master). Should be easy to reproduce by adding something like this to a file and then restarting gopls:
// #cgo pkg-config: some-library
import "C"

Ah, I just fixed that panic in CL 210215.

Hot dog! Yes, seems to start up fine now.

Perfect! So it sounds like we will wait for this fix to be implemented in go list.

I think this is one instance of a broader problem: execution errors (from running the compiler, linker, or other tools) are not connected back to go list -e output.
Fixing that would be too complicated for 1.14 at this point in the freeze. We should consider it for 1.15 though.

authors: jayconrod matloob muirdm stamblerre


text:
Nil pointer dereference on go generate

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

$ go version
go version go1.14 linux/amd64

Does this issue reproduce with the latest release?
Yes ( 1.14 is latest as of submitting this issue).
What operating system and processor architecture are you using (go env)?
This is running on CircleCi in a container based on golang:1.14
go env Output
# go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/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-build305414601=/tmp/go-build -gno-record-gcc-switches"

What did you do?
go generate
What did you expect to see?
No panic and no stack trace
What did you see instead?
go: downloading github.com/cenkalti/backoff/v4 v4.0.0
go: downloading github.com/codegangsta/cli v1.18.1
go: downloading github.com/Jeffail/tunny v0.0.0-20171107125207-452a8e97d6a3
go: downloading github.com/golang/geo v0.0.0-20181008215305-476085157cff
go: downloading gopkg.in/olivere/elastic.v5 v5.0.81
go: downloading github.com/xeipuuv/gojsonschema v1.1.0
go: downloading github.com/sirupsen/logrus v1.4.2
go: downloading github.com/pkg/errors v0.9.1
go: downloading github.com/aws/aws-sdk-go v1.25.37
go: downloading github.com/mcuadros/go-version v0.0.0-20180611085657-6d5863ca60fa
go: downloading golang.org/x/crypto v0.0.0-20200311171314-f7b00557c8c4
go: downloading github.com/go-redis/redis v6.7.5+incompatible
go: downloading github.com/mailru/easyjson v0.0.0-20180823135443-60711f1a8329
go: downloading github.com/scritchley/orc v0.0.0-20190122202601-8bd759130ab7
go: downloading github.com/scylladb/gocql v1.3.0
go: downloading github.com/ghodss/yaml v1.0.0
go: downloading github.com/multiplay/go-slack v0.0.0-20180305234526-6f89412cdb8c
go: downloading github.com/jmespath/go-jmespath v0.0.0-20180206201540-c2b33e8439af
go: downloading github.com/signalfx/golib v2.5.1+incompatible
go: downloading github.com/xeipuuv/gojsonreference v0.0.0-20180127040603-bd5ef7bd5415
go: downloading github.com/gorilla/mux v1.6.2
go: downloading golang.org/x/sys v0.0.0-20200302150141-5c8b2ff67527
go: downloading github.com/bradfitz/latlong v0.0.0-20170410180902-f3db6d0dff40
go: downloading github.com/prometheus/client_golang v1.3.0
go: downloading github.com/sha1sum/aws_signing_client v0.0.0-20170514202702-9088e4c7b34b
go: downloading googlemaps.github.io/maps v0.0.0-20190206003505-be134e760d70
go: downloading github.com/prometheus/client_model v0.1.0
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x45375d]

goroutine 83 [running]:
time.stopTimer(0xc000980468, 0x0)
	/usr/local/go/src/runtime/time.go:224 +0x2b
time.(*Timer).Stop(...)
	/usr/local/go/src/time/sleep.go:78
net/http.(*http2ClientConn).roundTrip(0xc000660780, 0xc00052c000, 0x0, 0x0, 0x0, 0x0)
	/usr/local/go/src/net/http/h2_bundle.go:7480 +0x9f
net/http.(*http2Transport).RoundTripOpt(0xc00036a1e0, 0xc00052c000, 0x9a1500, 0xc0008a6120, 0xc0005be3c0, 0x5)
	/usr/local/go/src/net/http/h2_bundle.go:6948 +0x16f
net/http.(*http2Transport).RoundTrip(...)
	/usr/local/go/src/net/http/h2_bundle.go:6909
net/http.http2noDialH2RoundTripper.RoundTrip(0xc00036a1e0, 0xc00052c000, 0xb2e0a0, 0xc00036a1e0, 0x0)
	/usr/local/go/src/net/http/h2_bundle.go:9103 +0x3e
net/http.(*Transport).roundTrip(0xebee00, 0xc00052c000, 0x0, 0xc000a469e8, 0x40e388)
	/usr/local/go/src/net/http/transport.go:515 +0xd94
net/http.(*Transport).RoundTrip(0xebee00, 0xc00052c000, 0xebee00, 0x0, 0x0)
	/usr/local/go/src/net/http/roundtrip.go:17 +0x35
net/http.send(0xc00052c000, 0xb2d3c0, 0xebee00, 0x0, 0x0, 0x0, 0xc000780090, 0x203000, 0x1, 0x0)
	/usr/local/go/src/net/http/client.go:252 +0x43e
net/http.(*Client).send(0xeb6520, 0xc00052c000, 0x0, 0x0, 0x0, 0xc000780090, 0x0, 0x1, 0xc00052c000)
	/usr/local/go/src/net/http/client.go:176 +0xfa
net/http.(*Client).do(0xeb6520, 0xc00052c000, 0x0, 0x0, 0x0)
	/usr/local/go/src/net/http/client.go:699 +0x44a
net/http.(*Client).Do(...)
	/usr/local/go/src/net/http/client.go:567
cmd/go/internal/web.get.func1(0xc0006ac080, 0xc0006ac080, 0x0, 0x0, 0x97a6c0)
	/usr/local/go/src/cmd/go/internal/web/http.go:96 +0x115
cmd/go/internal/web.get(0x1, 0xc000944fe8, 0x2, 0xc000152080, 0x31)
	/usr/local/go/src/cmd/go/internal/web/http.go:111 +0x19a
cmd/go/internal/web.Get(...)
	/usr/local/go/src/cmd/go/internal/web/api.go:183
cmd/go/internal/modfetch.(*proxyRepo).getBody(0xc0008e4200, 0xc00099a0d0, 0xd, 0xc00002bc80, 0x6, 0xa3658c, 0x4)
	/usr/local/go/src/cmd/go/internal/modfetch/proxy.go:266 +0x17d
cmd/go/internal/modfetch.(*proxyRepo).Zip(0xc0008e4200, 0xb2d620, 0xc000780048, 0xc00002bc80, 0x6, 0x0, 0x0)
	/usr/local/go/src/cmd/go/internal/modfetch/proxy.go:416 +0x1d7
cmd/go/internal/modfetch.(*cachingRepo).Zip(0xc000b7e0a0, 0xb2d620, 0xc000780048, 0xc00002bc80, 0x6, 0xc000b7e0a0, 0x0)
	/usr/local/go/src/cmd/go/internal/modfetch/cache.go:242 +0x5c
cmd/go/internal/modfetch.downloadZip.func2(0xa477b4, 0x18, 0x2, 0x0)
	/usr/local/go/src/cmd/go/internal/modfetch/fetch.go:214 +0xbd
cmd/go/internal/modfetch.TryProxies(0xc000945360, 0x40, 0xc0005be361)
	/usr/local/go/src/cmd/go/internal/modfetch/proxy.go:171 +0x9e
cmd/go/internal/modfetch.downloadZip(0xc000029320, 0x22, 0xc00002bc80, 0x6, 0xc0004a0d20, 0x4b, 0x0, 0x0)
	/usr/local/go/src/cmd/go/internal/modfetch/fetch.go:209 +0x2b8
cmd/go/internal/modfetch.DownloadZip.func1(0x0, 0x0)
	/usr/local/go/src/cmd/go/internal/modfetch/fetch.go:173 +0x2b3
cmd/go/internal/par.(*Cache).Do(0xec79a0, 0x9d7ac0, 0xc0007743c0, 0xc000a47538, 0xb2e260, 0xe77640)
	/usr/local/go/src/cmd/go/internal/par/work.go:128 +0xf3
cmd/go/internal/modfetch.DownloadZip(0xc000029320, 0x22, 0xc00002bc80, 0x6, 0xb2d680, 0xc000b84180, 0x35, 0x35)
	/usr/local/go/src/cmd/go/internal/modfetch/fetch.go:144 +0xd3
cmd/go/internal/modfetch.download(0xc000029320, 0x22, 0xc00002bc80, 0x6, 0xc00057f600, 0x35, 0xb2d680, 0xc000b84180)
	/usr/local/go/src/cmd/go/internal/modfetch/fetch.go:71 +0xca
cmd/go/internal/modfetch.Download.func1(0xec7960, 0x9d7ac0)
	/usr/local/go/src/cmd/go/internal/modfetch/fetch.go:52 +0xa2
cmd/go/internal/par.(*Cache).Do(0xec7960, 0x9d7ac0, 0xc000774380, 0xc000a47878, 0x801411, 0xc000a47980)
	/usr/local/go/src/cmd/go/internal/par/work.go:128 +0xf3
cmd/go/internal/modfetch.Download(0xc000029320, 0x22, 0xc00002bc80, 0x6, 0xc000a47900, 0x4a1841, 0x4f2587, 0xc0008d39b1)
	/usr/local/go/src/cmd/go/internal/modfetch/fetch.go:47 +0xef
cmd/go/internal/modload.fetch(0xc000029320, 0x22, 0xc00002bc80, 0x6, 0xffffffffffffffff, 0x30, 0x0, 0x0, 0xc0000fa200)
	/usr/local/go/src/cmd/go/internal/modload/load.go:1343 +0xfb
cmd/go/internal/modload.Import(0xc0008d39b1, 0x25, 0x3, 0x0, 0xffffffffffffffff, 0xc000150580, 0x8, 0x10, 0x0, 0x0)
	/usr/local/go/src/cmd/go/internal/modload/import.go:157 +0x1b6f
cmd/go/internal/modload.(*loader).doPkg(0xc0000be540, 0x9a58e0, 0xc0008ac460)
	/usr/local/go/src/cmd/go/internal/modload/load.go:770 +0x3c2
cmd/go/internal/par.(*Work).runner(0xc0003ca180)
	/usr/local/go/src/cmd/go/internal/par/work.go:101 +0x157
created by cmd/go/internal/par.(*Work).Do
	/usr/local/go/src/cmd/go/internal/par/work.go:67 +0x9b

This looks like #37400, which is fixed in the recent 1.14.1 release.  Please give that release a try.

authors: ianlancetaylor pmalekn


text:
encoding/xml: roll back case-insensitive xml check

Consider this program:
package main

import (
	"encoding/xml"
	"fmt"
	"log"
)

type Obj struct {
	SchemaLocation string `xml:"http://www.w3.org/2001/XMLSchema-instance schemaLocation,attr,omitempty"`
	Data           int
}

var x = Obj{"wherever", 9}

func main() {
	enc, err := xml.Marshal(&x)
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println(string(enc))
}

https://play.golang.org/p/i4ok93G8oUu
In Go 1.14, it prints
<Obj xmlns:XMLSchema-instance="http://www.w3.org/2001/XMLSchema-instance" XMLSchema-instance:schemaLocation="wherever"><Data>9</Data></Obj>

In Go 1.15 beta, it prints
<Obj xmlns:_XMLSchema-instance="http://www.w3.org/2001/XMLSchema-instance" _XMLSchema-instance:schemaLocation="wherever"><Data>9</Data></Obj>

Note the _ before XMLSchema.
This change from CL 203417 is documented in the release notes, but it and the release notes description should probably be rolled back. As implemented there is no way to emit this tag anymore - in Go 1.15 there seems to be no way to write a program that generates that output. We need to provide some way to keep programs like this from breaking, or at least to be able to fix them when they do break.
For Go 1.15, let's just roll back the change.

CC @odeke-em

But why?
According to https://github.com/golang/go/issues/35151#issuecomment-546290210, anything starting with xml should be treated as reserved.

@tgulacsi as Russ mentioned it introduces a breaking behavior, but we unfortunately have run out of time as Go1.15 will be released in a few days. Please don’t be discouraged, Go aims for as much compatibility and we have the Go1 compatibility promise to hold up as our mandate. We can try again early enough for Go1.16 and address both issues. Your contribution was awesome, and Russ even sent the release note for it. n Go1.16. I look forward to us tackling this again early for feedback, and I look forward to reviewing your changes again, if you’ve got bandwidth. Thank you!

I'm not offended, just flabbergasted :)
My original problem (#35151) had just the same example: XMLInstance.
If we can't change/specify the attribute namespace tag name, then how will we resolve this issue?
I just don't care about this shit thing XML with namespaces for beans, but sadly for living I have to interact with other Enterprise things that think XML is THE BEST thing for data interchange and RPC.
This XMLInstance issue came to me as the other end has reported it as an error.
So since then I'm replacing the attribute tags in the encoded XML - works, but really not nice: a hack.
My main question is for a real example where _XMLInstance causes problems: here it is not clarified!

@tgulacsi from doing extensive testing on internal targets we’ve identified some programs and/or tests that rely on the previous output. This is typically a signal that programs outside of the corpus of tests we run are also affected, so we are rolling back with the intention of trying again in Go 1.16. Again, this is not to say your change will never make it in, but when we make a call late in the cycle it’s typically a conservative one.
We do appreciate your contributions and are happy to revisit this in the next cycle.

@tgulacsi In particular it looks like we need some mechanism to let programs emit tags that start with "xml", even if that is technically invalid.  Those programs work today, and it doesn't seem like a good idea to break them without giving them a path forward.

authors: andybons ianlancetaylor odeke-em rsc tgulacsi