Could anyone explain this strange behaviour?

<p>I have been writing a compiler in Go and I have come across a very unusual issue. </p> <p>Here is the code I am debugging:</p> <pre><code>if t.SubType != nil { println(&#34;1: subtype of &#34;+token+&#34; is &#34;+t.SubType.Name) } ic.ExpressionType = t if t.SubType != nil { println(&#34;2: subtype of &#34;+token+&#34; is now &#34;+t.SubType.Name) } </code></pre> <p><del>An example context can be found <a href="https://play.golang.org/p/Zi2EO0RLC4" rel="nofollow">here</a> (Although this works as expected)</del></p> <p>I would expect that the assignment would not change the pointer value of t.SubType. The thing is, it does somehow. The problematic output I am getting is:</p> <pre><code>1: subtype of l is Int 2: subtype of l is now list </code></pre> <p>When I am expecting:</p> <pre><code>1: subtype of l is Int 2: subtype of l is now Int </code></pre> <p>When I comment out the line ic.ExpressionType = t Then I get the result I expected.</p> <p><del>Am I missing something here? Or could it be a bug with the Go compiler itself?</del></p> <p>Edit: it turns out &#39;t.SubType&#39; is pointing at ic.ExpressionType. </p> <hr/>**评论：**<br/><br/>google_you: <pre><p>come up with actual testcase that exhibits the strange behavior (assignment changes value of right hand side).</p></pre>Splizard: <pre><p>I have the actual compiler which I am writing.</p></pre>vAltyR47: <pre><p>But we can&#39;t see your actual code, and the example you&#39;ve given us works properly. This is not an actual test case because it doesn&#39;t exhibit the behavior you&#39;re describing.</p> <p>If you can&#39;t reproduce the bug reliably, there&#39;s nothing we can do to help you diagnose what&#39;s happening.</p> <p>EDIT: Thinking about it a different way, there&#39;s something different between your code and the example you&#39;ve given us. Did you write the playground example from scratch, or did you copy-paste your code in and it magically worked? If the former, then likely you have a typo in your code.</p></pre>Sythe2o0: <pre><p>Are there other goroutines running?</p></pre>Splizard: <pre><p>I have not started any with the &#34;go&#34; keyword, the program should be running sequentially.</p></pre>whizack: <pre><p>i mean the clear path to debugging this is finding assignments of the subtype &#39;list&#39;. it seems that ic.ExpressionType = t is just a red herring. </p> <p>Something is concurrently modifying the SubType pointer and you just so happen to have noticed it at this location.</p></pre>Splizard: <pre><p>There is only one goroutine running. The only concurrent logic would be from the Garbage Collector.</p></pre>whizack: <pre><p>it seems you have already figured it out, but yeah the next step would be to check your pointers for shenanigans.</p></pre>nhooyr: <pre><p>Don&#39;t use <code>println</code>. Use <code>fmt.Println</code>, see the comment on <a href="https://golang.org/pkg/builtin/#println" rel="nofollow">https://golang.org/pkg/builtin/#println</a></p></pre>Splizard: <pre><p>Yea, It&#39;s for debugging purposes, the code does not normally have println</p></pre>ChristophBerger: <pre><p>I think the more important point is the last half sentence of the <code>println</code> doc: </p> <blockquote> <p>it is not guaranteed to stay in the language.</p> </blockquote> <p>I usually use <code>davegch/spew</code> for quick, readable data dumps. Easy to add, easy to remove (as, like with <code>println</code>, you would not use <code>spew.Dump()</code> for anything other than debugging.)</p> <p>Also a great debugging help: <a href="https://godoc.org/github.com/kr/pretty" rel="nofollow"><code>kr/pretty</code></a>, a pretty printer that also can diff data structures. (Buz, if you read this: Thanks for pointing me to this one.)</p></pre>