Some of the issues in that doc should be addressed now (e.g., the first
two), but the "Assignment to indirect escapes" case still applies.
The issue here is we don't do any points-to analysis during escape
analysis, so we conservatively assume "*p = x" might assign x to the heap.
Ideally, I think
[ +mdempsky ]
On Thu, Mar 5, 2020 at 2:58 AM Ethan Burns wrote:
>
> Thanks. I'll give that doc a read. Just to make sure, I noticed that the doc
> is dated 2015, but the escape analysis implementation seemed to change just
> recently from that implemented in esc.go to a new one in escape.go. Do
Thanks. I'll give that doc a read. Just to make sure, I noticed that the
doc is dated 2015, but the escape analysis implementation seemed to change
just recently from that implemented in esc.go to a new one in escape.go.
Dose the doc still apply to the new implementation?
On Thu, Mar 5, 2020 at 4:
This is a known deficiency of Go's escape analysis, which is recorded in
this doc:
https://docs.google.com/document/d/1CxgUBPlx9iJzkz9JWkb6tIpTe5q32QDmz8l0BouG0Cw/view#
On Thursday, March 5, 2020 at 5:58:37 AM UTC+8, burns...@gmail.com wrote:
>
> Hi All,
>
> I am trying to debug why a byte slice
Thanks for looking into it and simplifying the example!
Just to explain, I added the call to nothing(), because I was worried that
otherwise the result would be recognized as unused and the entire code
would be optimized away. Good to know it's not relevant to reproduce.
Thanks again.
On Wed, Mar
Slightly more minimal, in my testing it seems that the call to 'nothing' is
not needed.
I do not quite know why, but these two lines seem to show how the compiler
is reasoning about this escape:
escape.go:4:11: flow: {heap} = x:
escape.go:4:11: from *y = x (assign) at escape.go:6:5
I do
