feat(C & JS API)!: Add BinaryenHasMemorySegment

[spotandjake]

This pr implements BinaryenDataSegmentRef in the binaryen c api.

The corresponding BinaryenGetMemorySegment and BinaryenGetMemorySegmentByIndex can be used in the c-api to get a memory segment, and module.getMemorySegment and module.getMemorySegmentByIndex can be used in the js api. BinaryenGetMemorySegmentByteOffset, BinaryenGetMemorySegmentByteLength, BinaryenGetMemorySegmentPassive and BinaryenCopyMemorySegmentData to take a BinaryenDataSegmentRef were converted to take a segmentRef as opposed to names, and getMemorySegmentInfo was converted in the js api. Additionally BinaryenGetMemorySegmentName was implemented to retreive the segment name from a reference and the js api was modified to return this as part of the info.

Motivation:

While adding a test to the grain compiler to check the size of a generated memory segment, I noticed that if the segment didn't exist, any operations on that segment would throw. As we are working from OCaml, we have no way to catch this fatal C++ exception related grain pr. As far as I am aware there is no other existing way to check if a segment exists, this change allows a user to use getMemorySegment which will return NULL if the segment doesn't exist.

getMemorySegment allows a user to check for the existance of a segment before trying to perform operations on it.

Related Binaryen.ml Issue
Related Grain issue

[kripken]

The current BinaryenGetFunction etc. return null if the thing is not present. Can we use the same pattern here, adding BinaryenGetDataSegment? Otherwise this has* seems like it would be a novel pattern in the C API.

[spotandjake]

The current BinaryenGetFunction etc. return null if the thing is not present. Can we use the same pattern here, adding BinaryenGetDataSegment? Otherwise this has* seems like it would be a novel pattern in the C API.

I certainly could implement a BinaryenGetDataSegment however I wanted to note that currently there is no concept of MemorySegmentRef. The behaviour of BinarenGetFunction seems fundamentally different as it returns FunctionRef, I took the Has syntax from inspiration from BinaryenHasMemory, BinaryenHasPassToSkip, BinaryenFunctionHasLocalName though i'm not sure any of those examples are exaclty the same either.

The options I see going forward here would be:

• Make all the memory segment opertaions return NULL instead of throwing if the segment doesn't exist (this doesn't feel super explcit to me so i'm not the biggest fan of this behaviour.
• Add a BinaryenGetDataSegment function, add a MemorySegmentRef, deprecate the existing name basedMemorySegment operations and implement reference based operations
• The approach I currently took.

I am happy todo any one of those, I just wanted to make sure the pr scope was clear before implementing.

[kripken]

I took the Has syntax from inspiration from BinaryenHasMemory, BinaryenHasPassToSkip, BinaryenFunctionHasLocalName though i'm not sure any of those examples are exaclty the same either.

Makes sense, but yeah, those are quite different. "HasMemory" is back from the time before multimemory, when a memory existed or did not, and the other properties are quite special.

I certainly could implement a BinaryenGetDataSegment however I wanted to note that currently there is no concept of MemorySegmentRef.

I think it makes sense to add that concept.

[spotandjake]

I made those changes. This pr is now breaking.

[kripken]

Is this pattern needed? I don't see it elsewhere

[spotandjake]

I figured the function should return null if the segment doesn't exist, I can remove it if it should be returning 0 instead though.

[kripken]

Maybe it would be nicer as you suggest, but for consistency let's do it as other places do. We could consider changing the API in general separately.