Why is C++ used rather than C about tree-sitter-python

[issue-label-bot]

Issue-Label Bot is automatically applying the label question to this issue, with a confidence of 0.95. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[maxbrunsfeld]

I use it from Rust myself and have found it painless, since libc++/libstdc++ is available in almost every environment where a C compiler is available. C++ is also used in external scanners of other languages.

In the case of that file, we use C++ because of std::vector and std::string.

[maxbrunsfeld]

Did you try the cpp method? It should just work.

[mcobzarenco]

Thanks for this @maxbrunsfeld, would you mind sharing your build.rs that links with libstdc++? Have you tried linking statically (musl needs some shimming as it doesn't support C++ out of the box)? On nightly, the following build directive is useful (but still won't just work without rebuilding libstdc++ against musl):

println!("cargo:rustc-link-lib=static=stdc++");

[mcobzarenco]

Ha! Thanks for that, it does help set up the env for dynlib case (static linking against C++ still requires recompiling libstd++ against musl, I think).

However, it seems that compiling parser.c with a C++ compiler rather than C doesn't work -- I am getting pages of the following:

...
cargo:warning=grammars/tree-sitter-python/src/parser.c:40434:3: sorry, unimplemented: non-trivial designated initializers not supported
cargo:warning=grammars/tree-sitter-python/src/parser.c:40434:3: sorry, unimplemented: non-trivial designated initializers not supported
cargo:warning=grammars/tree-sitter-python/src/parser.c:40434:3: sorry, unimplemented: non-trivial designated initializers not supported
cargo:warning=grammars/tree-sitter-python/src/parser.c:40434:3: sorry, unimplemented: non-trivial designated initializers not supported
...

This seems to be as parser.c uses designated initializers syntax (i.e. .field = value) which is not valid C++ according to the standard:

Note: out-of-order designated initialization, nested designated initialization, mixing of designated initializers and regular initializers, and designated initialization of arrays are all supported in the C programming language, but are not allowed in C++.

[maxbrunsfeld]

Yeah, I think you need a c build and a C++ build.

[mcobzarenco]

Gotcha, makes sense -- I got it to work, thank you for the help.

[mcobzarenco]

FWIW, using C++ does seem to preclude static linking using musl

[maxbrunsfeld]

Yeah, if you're trying to avoid dependencies on libc/libc++, I can see how this would complicate things.

One reference I might use is Emscripten, which compiles code written in both C and C++ into self-contained WebAssembly bindings using mostly-unmodified source files from libc++.

I think that you could probably use the same approach to create a statically-linked native binary, by adding several source files and include flags from libc++ to your build.