title: Use fork of standard library to patch go/ast
body: <p>I fixed a tiny bug in <code>go/ast</code> (see the following <a href="https://github.com/golang/go/issues/39753" rel="nofollow noreferrer">Github issue</a>). I would like to already use my fix in the project I am developing. The fork that contains the fix is available on <a href="https://github.com/ec-m/go" rel="nofollow noreferrer">https://github.com/ec-m/go</a>.</p>
  <p>First, I tried the following imports:</p>
  <pre><code>import &quot;github.com/ec-m/go/src/go/ast&quot;
  </code></pre>
  <p>and</p>
  <pre><code>import &quot;github.com/ec-m/go&quot;
  </code></pre>
  <p>which resulted in various <code>go get</code> errors like <code>module github.com/ec-m/go/src@upgrade found (v0.0.0-20200626183851-7b0f14cb18cb), but does not contain package github.com/ec-m/go/src/go</code>.</p>
  <p>Then, I followed the regular approach of using forked dependencies outlined unter
  <a href="https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive" rel="nofollow noreferrer">https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive</a>
  and also mentioned in various questions, f. ex. <a href="https://stackoverflow.com/questions/61311436/how-to-fix-parsing-go-mod-module-declares-its-path-as-x-but-was-required-as-y">How to fix parsing go.mod module declares its path as &quot;x&quot; but was required as &quot;y&quot;</a>.</p>
  <p>Specifically, I included the following replace command in my <code>go.mod</code></p>
  <pre><code>replace go/ast =&gt; github.com/ec-m/go v0.0.0-20200626183851-7b0f14cb18cb
  </code></pre>
  <p>This and some other tries (<code>std</code> instead of <code>go/ast</code> etc) did not work. After some research, I found out that replacing the standard library of Go is not possible (see this <a href="https://github.com/golang/go/issues/35283" rel="nofollow noreferrer">Github proposal</a>).</p>
  <p>What other option do I have to use my fork of the standard library of Go? I would like the approach to be as simple as possible in order avoid dependency struggles for future users of my project.</p>