update go-ffmpreg to v0.2.5 (pulls in latest tetratelabs/wazero) (#3203)

1 files changed, 0 insertions, 36 deletions

diff --git a/vendor/github.com/tetratelabs/wazero/internal/platform/platform.go b/vendor/github.com/tetratelabs/wazero/internal/platform/platform.go
index c6dc0f857..a27556240 100644
--- a/vendor/github.com/tetratelabs/wazero/internal/platform/platform.go
+++ b/vendor/github.com/tetratelabs/wazero/internal/platform/platform.go
@@ -36,28 +36,6 @@ func MmapCodeSegment(size int) ([]byte, error) {
 	}
 }
 
-// RemapCodeSegment reallocates the memory mapping of an existing code segment
-// to increase its size. The previous code mapping is unmapped and must not be
-// reused after the function returns.
-//
-// This is similar to mremap(2) on linux, and emulated on platforms which do not
-// have this syscall.
-//
-// See https://man7.org/linux/man-pages/man2/mremap.2.html
-func RemapCodeSegment(code []byte, size int) ([]byte, error) {
-	if size < len(code) {
-		panic("BUG: RemapCodeSegment with size less than code")
-	}
-	if code == nil {
-		return MmapCodeSegment(size)
-	}
-	if runtime.GOARCH == "amd64" {
-		return remapCodeSegmentAMD64(code, size)
-	} else {
-		return remapCodeSegmentARM64(code, size)
-	}
-}
-
 // MunmapCodeSegment unmaps the given memory region.
 func MunmapCodeSegment(code []byte) error {
 	if len(code) == 0 {
@@ -65,17 +43,3 @@ func MunmapCodeSegment(code []byte) error {
 	}
 	return munmapCodeSegment(code)
 }
-
-// mustMunmapCodeSegment panics instead of returning an error to the
-// application.
-//
-// # Why panic?
-//
-// It is less disruptive to the application to leak the previous block if it
-// could be unmapped than to leak the new block and return an error.
-// Realistically, either scenarios are pretty hard to debug, so we panic.
-func mustMunmapCodeSegment(code []byte) {
-	if err := munmapCodeSegment(code); err != nil {
-		panic(err)
-	}
-}