Review Go 1.9 release notes

[Brad Fitzpatrick]

Please do a final read of the Go 1.9 release notes:

    https://tip.golang.org/doc/go1.9

They should be complete now.

Leave comments here:

    https://golang.org/cl/47610

[Austin Clements]

To better prepare users for upcoming improvements to inlining, should the release notes more prominently encourage using runtime.CallersFrames instead of directly inspecting the slice returned by runtime.Callers? CallersFrames has been available for a few releases now, but we've never been very loud about using it.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Fitzpatrick]

SGTM

You should also update the docs on

https://tip.golang.org/pkg/runtime/#FuncForPC

with a pointer to the better way.

[Austin Clements]

Okay. I'll send something once I figure out where to put it in the document. :)

On Thu, Jul 6, 2017 at 11:52 AM, Brad Fitzpatrick <brad...@golang.org> wrote:

SGTM

You should also update the docs on

https://tip.golang.org/pkg/runtime/#FuncForPC

with a pointer to the better way.

This is documented at https://tip.golang.org/pkg/runtime/#Callers, since that's the entry point to trouble. I suppose FuncForPC could say what happens if there are multiple inlined frames at pc...

[Austin Clements]

On Thu, Jul 6, 2017 at 12:13 PM, Eddie Ringle <ed...@mobomo.com> wrote:

> To better prepare users for upcoming improvements to inlining

Sorry this is slightly off the topic of this thread, but are you referring to mid-stack inlining? I thought that was targeted for 1.9? (Though looking at the release notes I see no mention of it, now.)

Yes.

It was originally targeted for 1.9, but it turns out to significantly slow down build times and has a non-trivial impact on binary size. The mechanism is all there, but it's not enabled by default for 1.9. We planning to fix the build time problem by significantly improving export data efficiency for 1.10 and may revisit some of the inlining heuristics to improve binary size impact.

Some of the effects of this work will still be visible in 1.9. For example, stack traces from inlined leaf functions are finally correct (no more "but I don't even index a slice on that line" panics :).

[Eddie Ringle]

> To better prepare users for upcoming improvements to inlining

Sorry this is slightly off the topic of this thread, but are you referring to mid-stack inlining? I thought that was targeted for 1.9? (Though looking at the release notes I see no mention of it, now.)

- Eddie

On Thu, Jul 6, 2017 at 11:02 AM 'Austin Clements' via golang-dev <golan...@googlegroups.com> wrote:

Okay. I'll send something once I figure out where to put it in the document. :)

On Thu, Jul 6, 2017 at 11:52 AM, Brad Fitzpatrick <brad...@golang.org> wrote:

SGTM

You should also update the docs on

https://tip.golang.org/pkg/runtime/#FuncForPC

with a pointer to the better way.

This is documented at https://tip.golang.org/pkg/runtime/#Callers, since that's the entry point to trouble. I suppose FuncForPC could say what happens if there are multiple inlined frames at pc...

On Thu, Jul 6, 2017 at 8:47 AM, Austin Clements <aus...@google.com> wrote:

To better prepare users for upcoming improvements to inlining, should the release notes more prominently encourage using runtime.CallersFrames instead of directly inspecting the slice returned by runtime.Callers? CallersFrames has been available for a few releases now, but we've never been very loud about using it.

On Thu, Jul 6, 2017 at 10:33 AM, Brad Fitzpatrick <brad...@golang.org> wrote:

Please do a final read of the Go 1.9 release notes:

    https://tip.golang.oTo better prepare users for upcoming improvements to inliningrg/doc/go1.9

They should be complete now.

Leave comments here:

    https://golang.org/cl/47610

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Russ Cox]

I sent a pair of CLs with tiny changes. Overall they look great. Thanks very much for coordinating all that work, and thanks to everyone who contributed. 

Russ

On Thu, Jul 6, 2017 at 10:33 AM, Brad Fitzpatrick <brad...@golang.org> wrote:

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

[Dmitri Savintsev]

Is it too late to add something to the 1.9 release notes at this point? https://github.com/golang/go/issues/21289 - 'go1.9 release notes: add missing "crypto/x509: ignore CN if SAN extension present" change'.  Could help users figuring out why they get "new" errors in certificate validation with go1.9. Thanks.

[Ian Lance Taylor]

On Thu, Aug 3, 2017 at 6:50 AM, Dmitri Savintsev <dsav...@gmail.com> wrote:
>
> Is it too late to add something to the 1.9 release notes at this point?
> https://github.com/golang/go/issues/21289 - 'go1.9 release notes: add
> missing "crypto/x509: ignore CN if SAN extension present" change'. Could
> help users figuring out why they get "new" errors in certificate validation
> with go1.9. Thanks.

It is not too late. Can you send a change? Thanks.

Ian

[m...@fly.io]

I just noticed that https://tip.golang.org/pkg/net/http/#ServeTLS is missing from release notes in https://tip.golang.org/doc/go1.9#net/http. Was that intentional?

Best,
Mat

[Ian Lance Taylor]

On Wed, Aug 9, 2017 at 11:50 AM, <m...@fly.io> wrote:
>
> I just noticed that https://tip.golang.org/pkg/net/http/#ServeTLS is missing
> from release notes in https://tip.golang.org/doc/go1.9#net/http. Was that
> intentional?

I don't think so. Want to send a patch?

Ian

[Mat Byczkowski]

Sure!

This is my first patch, so I'm not sure if I've done it right https://go-review.googlesource.com/54411

--

 - mat

[knw...@gmail.com]

IMHO the Go 1.9 release notes should prominently mention that the html/template changes are backward-incompatible. Quoting one of the html/template commit messages:

NOTE: this is a backward-incompatible change that fixes known security bugs (see linked issues for more details). It will explicitly break users that attempt to execute templates with pipelines containing predefined escapers.

E.g. I found the following regression testing Prometheus v1.7.1 compiled with go1.9rc2:

Issue #3046 : targets.html: predefined escaper "html" disallowed in template (with go1.9rc2)

(Sorry, I can't send a patch myself this time.)

[Samuel Tan]

IMHO the Go 1.9 release notes should prominently mention that the html/template changes are backward-incompatible. 

Ack, this is probably a good idea.

[Russ Cox]

For what it's worth, that commit message is inaccurate because later commits amended the behavior. Specifically, the release notes say of html/template:

The package now reports an error if a predefined escaper (one of "html", "urlquery" and "js") is found in a pipeline and does not match what the auto-escaper would have decided on its own. This avoids certain security or correctness issues. Now use of one of these escapers is always either a no-op or an error. (The no-op case eases migration from text/template.)

The difference is that the commit you found suggests they're taken out entirely, and they're not. They're rejected where they're incorrect and unsafe.

Russ

On Fri, Aug 11, 2017 at 1:17 PM, 'Samuel Tan' via golang-dev <golan...@googlegroups.com> wrote:

IMHO the Go 1.9 release notes should prominently mention that the html/template changes are backward-incompatible. 

Ack, this is probably a good idea.

On Thursday, August 10, 2017 at 8:47:58 AM UTC-7, Karsten Weiss wrote:

IMHO the Go 1.9 release notes should prominently mention that the html/template changes are backward-incompatible. Quoting one of the html/template commit messages:

NOTE: this is a backward-incompatible change that fixes known security bugs (see linked issues for more details). It will explicitly break users that attempt to execute templates with pipelines containing predefined escapers.

E.g. I found the following regression testing Prometheus v1.7.1 compiled with go1.9rc2:

Issue #3046 : targets.html: predefined escaper "html" disallowed in template (with go1.9rc2)

(Sorry, I can't send a patch myself this time.)

--

[Samuel Tan]

The difference is that the commit you found suggests they're taken out entirely, and they're not. They're rejected where they're incorrect and unsafe.

This is true, and I think the patch notes do a good job of stating this nuance. The backward-incompatibility of this change is also already implied.

Still, explicitly calling this out (e.g. "This is a backward-compatible change") might make this change stand out more to a developer who is scrolling through the patch notes. Feel free to ignore my suggestion, though.