Exclude APIs that dup given file descriptors from WASI builds

[kateinoigakukun]

WASI doesn't support dup(2) system call, so we cannot implement the print_dot_graph and print_dot_graphs functions with exactly the same semantics as in other platforms.

In file included from ChimeHQ/SwiftTreeSitter/Packages/tree-sitter/lib/src/lib.c:13:
ChimeHQ/SwiftTreeSitter/Packages/tree-sitter/lib/src/./tree.c:156:10: error: call to undeclared function 'dup'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  156 |   return dup(file_descriptor);
      |          ^
1 error generated.

If we really need those functionalities in WASI, we can provide new variants of them that consumes the given fds.

---

Alternative consideration

If we can accept semantics changes on the fd consumption for those public APIs, we can provide those APIs without adding new variants.

[maxbrunsfeld]

Maybe the ideal fix would be to move away from using fdopen at all, and write to the file descriptor directly with ‘write’. We could buffer the input ourselves using snprintf

[maxbrunsfeld]

I’m fine with this change for now. I don’t want to change the semantics to consume the fd.

[kateinoigakukun]

@maxbrunsfeld Even if we write contents by write(2) directly, it changes the offset of the fd. So if we want to keep the current semantics (user provided fd should not change its offset), we still need to dup the fd IIUC.

[maxbrunsfeld]

Oh, good point. I think that is a fine semantics change though. I don’t think it’s as disruptive as taking ownership of the file descriptor.

[tree-sitter-ci-bot]

Successfully created backport PR for release-0.23:

• Exclude APIs that dup given file descriptors from WASI builds #3707