[go1.20] Added support for unsafe.SliceData #1298
Conversation
|
In general, I am in favor of implementing |
|
I wonder if This would allow GopherJS authors to run, say, |
That sounds like a perfect use case for https://github.com/gopherjs/gopherjsvet 😉 |
I hit a blocker with that project, with a lack of support for abritrary tags in the upstream tools. But I think we can work around it just by forking the upstream (as I've seen done in a few other projects)... so when I have time, I'll try to get that project back off life support. |
4b74947 to
a1a5345
Compare
65f26dc to
a19f8ed
Compare
go1.20 added
unsafe.SlideData,unsafe.String, andunsafe.StringData.For the following reasons, this PR only adds
unsafe.SliceData. The tests for this change are in the Go repo tests of this builtin function. This is part of #1270SliceData
unsafe.SliceDatais something that GopherJS can handle because of how, even when empty, GopherJS slices have an array that can be pointed to.The only thing we can't handle is how using the "unspecified memory address" works right now, seen in this playground, but there are no promises for how that should work and no one should be using that pointer like that. In GopherJS assigning to the pointer of the empty slice simply writes to
[0]on the empty slice which then isn't visible, always returns zero, and is a pointless, but doesn't break anything.The Go compiler ensures that the argument into
SliceDatawill be a slice.String
unsafe.Stringmay be possible to support withBufferbut would require copying the data into a string. We should probably override it where possible because the point of this function is to not require a copy to be faster than simply performing a conversion,string([]byte{...}).We may need to we can add this later (with the copy) since it seams like some natives are using this instead of the cast to save memory and/or time. Instead of overriding each location, we could just stub out the cast (kind of like how we didn't override all the atomics but just stubbed out the atomic methods).
StringData
unsafe.StringDatamay be possible via a copy to a byte array first but is the same as above, doing the copy makes this no better than a conversion. Or we could make some JS code similar to$indexPtrthat wraps a string into a byte pointer. Until then we should probably override them instead.Also, this is super unsafe because in Go if you get the string data for a literal and attempt to modify it (despite the comment in the docs saying
*byteshould be treated as immutable) it causes a segmentation fault because you can't modify the literal stored in the memory with the opcode. The fault signal can not be recovered from. Here's a playground with that.