Today while attempting to integrate a test JS wrapper for the cache API released for webkit, a previous compile work but all new compiles consistently errored out due to a stack overflow error. Having established it is not the Go code in question I hoped any could help.

The problem arises when goperhjs attempts to retrieving the functions argument type for a promise, but instead cycles out till stack memory is depleted

WebCache Doc: https://developer.mozilla.org/en-US/docs/Web/API/Cache
WebCache API: https://github.com/gu-io/gu/blob/develop/shell/cache/webcache/webcache.go#L62-L66

Example Code:

package main

import (
	"honnef.co/go/js/dom"

	"github.com/gu-io/gu/shell/cache/webcache"
)

func main() {
	doc := dom.GetWindow().Document().(dom.HTMLDocument)
	body := doc.QuerySelector("body").(*dom.HTMLBodyElement)

	webCache, err := webcache.New()
	if err != nil {
		body.AppendChild(doc.CreateTextNode(err.Error()))
		body.AppendChild(doc.CreateElement("br"))
	}

	cache, err := webCache.Open("debi.v1") // issue arises here.
	if err != nil {
		body.AppendChild(doc.CreateTextNode(err.Error() + "\n"))
		body.AppendChild(doc.CreateElement("br"))
		return
	}

	err = cache.Add("http://localhost:8080/github.com/gu-io/gu/shell/")
	if err != nil {
		body.AppendChild(doc.CreateTextNode(err.Error()))
		body.AppendChild(doc.CreateElement("br"))
	}

	res, err := cache.MatchPath("http://localhost:8080/github.com/gu-io/gu/shell/", webcache.MatchAttr{})
	if err != nil {
		body.AppendChild(doc.CreateTextNode(err.Error()))
		body.AppendChild(doc.CreateElement("br"))
		return
	}

	item := doc.CreateElement("div")
	item.SetInnerHTML(string(res.Body))

	body.AppendChild(item)
	body.AppendChild(doc.CreateElement("br"))
}

Error Received:

main.js:2058 Uncaught (in promise) RangeError: Maximum call stack size exceeded
    at searchJsObject (main.js:2058)
    at searchJsObject (main.js:2070)
    at searchJsObject (main.js:2067)
    at searchJsObject (main.js:2070)
    at searchJsObject (main.js:2067)
    at searchJsObject (main.js:2070)
    at searchJsObject (main.js:2067)
    at searchJsObject (main.js:2070)
    at searchJsObject (main.js:2067)
    at searchJsObject (main.js:2070)
    at searchJsObject (main.js:2067)
    //-------------------MORE---OF---THE---SAME--------//
    at searchJsObject (main.js:2070)
    at searchJsObject (main.js:2067)
    at searchJsObject (main.js:2070)
    at searchJsObject (main.js:2067)
    at searchJsObject (main.js:2067)
    at searchJsObject (main.js:2067)
    at searchJsObject (main.js:2070)
    at $internalize (main.js:2081)
    at $internalize (main.js:2032)
    at v.$externalizeWrapper (main.js:1872)

The above stack trace has been shortened due to its large length.

GoperhJS Code In Question:
https://github.com/gopherjs/gopherjs/blob/master/compiler/prelude/jsmapping.go#L343-L371

It seems to be blowing up at the area of retrieving a pointer to the object response when using a promise.

Expected Response:
No SearchJsObject error when calling a Promise.

Any help would truly be appreciated. I attempted to resolve the issues with some changes to the jsmapping.go region as linked above but failed, I assumed if we capped the depth since it was causing a repetition of the same t.Fields[0] and t pointer then it was properly a cyclical issue, but failed because the object received was not the appropriate *js.Object pointing to the cache instance. Irony is v matches the instance of the cache object in JS land but not sure how to resolve the cycle and attached it properly to a pointer in Go land within the jsmapping, but figuring out a means to stop the recurring call to check the same t and t.Field[0] which were the same with each call to searchJSObject and adequately get this area

var f = t.fields[0];
        var o = searchJsObject(f.typ);
        if (o !== noJsObject) {
          var n = new t.ptr();
          n[f.prop] = o;
          return n;
        }

executed properly seems to be the issue.

Thanks.