`getenv()` should probably be a blessed stdlib-symbol for WASM builds?

[Davis Vaughan]

Problem

i.e. maybe include it in here https://github.com/tree-sitter/tree-sitter/blob/master/lib/src/wasm/stdlib-symbols.txt

Since external scanners are now intended to do something like getenv("TREE_SITTER_DEBUG") to check for debug mode, it seems like getenv() may be reasonable to include as a function for WASM builds?

Steps to reproduce

Use getenv() in an external scanner and then compile to wasm, it will fail.

Expected behavior

Expected to be able to use getenv() in an external scanner for detecting tree-sitter debug mode

Tree-sitter version (tree-sitter --version)

tree-sitter 0.21.0

Operating system/version

macOS 13.6.5

[ObserverOfTime]

Does debug mode need to be detected on runtime or would checking a flag during compilation be enough? 🤔

[ObserverOfTime]

Adding getenv to the stdlib breaks wasm tests:

---- tests::wasm_language_test::test_load_wasm_rust_language stdout ----
thread 'tests::wasm_language_test::test_load_wasm_rust_language' panicked at cli/src/tests/wasm_language_test.rs:70:56:
called `Result::unwrap()` on an `Err` value: WasmError { kind: Instantiate, message: "unexpected import in wasm stdlib: environ_get\n" }


failures:
    tests::wasm_language_test::test_load_and_reload_wasm_language
    tests::wasm_language_test::test_load_multiple_wasm_languages
    tests::wasm_language_test::test_load_wasm_errors
    tests::wasm_language_test::test_load_wasm_html_language
    tests::wasm_language_test::test_load_wasm_javascript_language
    tests::wasm_language_test::test_load_wasm_ruby_language
    tests::wasm_language_test::test_load_wasm_rust_language
    tests::wasm_language_test::test_wasm_oom

[Davis Vaughan]

Ah, it might not even be applicable in WASM, not sure. Regardless, I'm fairly certain I can work around it anyways and just enable debugging locally when I need to. Thanks for looking into it though. Feel free to close if you don't think there is anything else to do.

---

Re:

Does debug mode need to be detected on runtime or would checking a flag during compilation be enough?

Having a compile time flag seems like it would be enough for me

[Amaan Qureshi]

No, it should not. for debugging you can just check for TREE_SITTER_INTERNAL_BUILD being defined and run tree-sitter parse with the -0 option to build with this debug flag

[ObserverOfTime]

#3188 removes TREE_SITTER_INTERNAL_BUILD and defines NDEBUG in release builds so you can check for that if merged.