parse unsafe extern blocks

[m4rch3n1ng]

fixes: #250

i couldn't find a way to properly resolve the conflict between unsafe extern "C" fn and unsafe extern "C" {} without adding them to the conflicts field for now. if you have an idea on how to do that better then i would like.

specified here, here and here

regarding #229:

diff

--- .tmp/list.txt	2025-02-28 16:16:12.002933806 +0100
+++ .tmp/list.txt.unsafe-extern-mod	2025-02-28 19:10:18.478498116 +0100
@@ -1,7 +1,6 @@
 tests/codegen/dst-offset.rs
 tests/codegen/sanitizer/cfi/emit-type-metadata-id-itanium-cxx-abi-user-defined-types.rs
 tests/codegen/function-arguments.rs
-tests/codegen/terminating-catchpad.rs
 tests/coverage/attr/nested.rs
 tests/coverage/coroutine.rs
 tests/coverage/coverage_attr_closure.rs
@@ -216,7 +215,6 @@
 tests/ui/parser/keyword-union-as-identifier.rs
 tests/ui/parser/parser-unicode-whitespace.rs
 tests/ui/parser/trait-plusequal-splitting.rs
-tests/ui/parser/unsafe-foreign-mod.rs
 tests/ui/pattern/issue-22546.rs
 tests/ui/pattern/usefulness/integer-ranges/issue-117648-overlapping_range_endpoints-false-positive.rs
 tests/ui/privacy/decl-macro-infinite-global-import-cycle-ice-64784.rs
@@ -230,8 +228,6 @@
 tests/ui/rust-2018/try-macro.rs
 tests/ui/rust-2018/uniform-paths/from-decl-macro.rs
 tests/ui/rust-2018/uniform-paths/macro-rules.rs
-tests/ui/rust-2024/unsafe-extern-blocks/extern-items.rs
-tests/ui/rust-2024/unsafe-extern-blocks/safe-items.rs
 tests/ui/simd/masked-load-store.rs
 tests/ui/sized/coinductive-1-gat.rs
 tests/ui/specialization/assoc-ty-graph-cycle.rs

[maxbrunsfeld]

If possible, it would be cool to avoid the conflict by making the structure of function items and external blocks (and maybe other types of items) more consistent with each other. Generally, I'm ok with parsing a superset of what is actually allowed, if it gets us more consistency. Do you think there is any unification that makes sense between functions' modifiers, and extern blocks modifiers, and possibly any other items' modifiers?

[m4rch3n1ng]

last time i checked i thought this would be almost (if not outright) impossible, but thanks to your pointer (and actually learning more about tree-sitter over the last like month) i actually managed to do it without the conflict! very satisfying, though you can now write a const unsafe extern "C", which should be fine(?)

now just one more rebase ...

[maxbrunsfeld]

though you can now write a const unsafe extern "C", which should be fine(?)

Yeah, I'm generally ok with stuff like that. Seems like arguably a semantic error, as opposed to a syntactic one.

Just curious - how is the parser table size (STATE_COUNT) with this approach vs with the conflict?

[m4rch3n1ng]

with this version it's 3861, with the conflict it's 3856. on master it's 3823.

[maxbrunsfeld]

Ok, pretty small delta either way.

[m4rch3n1ng]

ci still doesn't work :(
(though it works for me locally?)

[maxbrunsfeld]

Are you generating it with the latest tree-sitter-cli?

[m4rch3n1ng]

i think so?

$ tree-sitter -V
tree-sitter 0.25.3 (2a835ee029dca1c325e6f1c01dbce40396f6123e)

[m4rch3n1ng]

ok when i do a fresh clone of the repo, run npm install and then node --test bindings/node/*_test.js it doesn't work for me on master (commit 3691201) either. if i go back to the last commit before changing the abi to version 15 (3d087c3) that does work for me. i have no idea what is going on and i do not know how to fix it though sorry.

[m4rch3n1ng]

if i do tree-sitter init and just default everything, then do tree-sitter generate, npm install (and npm add tree-sitter as otherwise i get a module tree-sitter not found error) and then do npm test the exact same happens:

though i am not sure where i should report that to exactly.