Keep up with breaking JuliaSyntax changes

[davidanthoff]

@c42f some patch release after 0.3.0 for JuliaSyntax must have been breaking, without the changes in this PR here things that worked with 0.3.0 are no longer working with 0.3.3. I think I hopefully have caught up now with these changes, but just thought I'd let you know, it should probably have been a minor release somewhere in there :)

[codecov[bot]]

Codecov Report

Merging #9 (a7d35a0) into main (bcc6a55) will not change coverage. The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main       #9   +/-   ##
=======================================
  Coverage   74.35%   74.35%           
=======================================
  Files           8        8           
  Lines         776      776           
=======================================
  Hits          577      577           
  Misses        199      199           

Flag	Coverage Δ
unittests	74.35% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/semantic_pass_toml_files.jl	94.23% <ø> (ø)
src/JuliaWorkspaces.jl	92.89% <100.00%> (ø)
src/semantic_pass_tests.jl	91.82% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[c42f]

Thanks for the heads up.

This is because

• The API of SyntaxNode is informal / poorly documented, and therefore
• You're digging into the internals of SyntaxNode
• There were changes in JuliaLang/JuliaSyntax.jl#193 which modified those internals

There's some functions to access the tree:

• children(node) instead of node.children (previously aliased with node.val)
• haschildren(node) instead of length(node.children)>0
• child(node, 1) or simply node[1], instead of node.children[1] (note, you can dig into the tree with child(node, 1, 2) instead of node[1][2])
• node.val should be ok to use I guess.

[davidanthoff]

Ah, excellent to know! https://github.com/julia-vscode/JuliaWorkspaces.jl/pull/11 uses this better API.

Also, major Julia gripe: that there is no way to actually really ever know what any given package considers internals that can break at any point and what the package considers its external/public API. Essentially the only tool we have is documentation, which is really not a good tool at all. I appreciate that we can always dig into everything, but at the same time it would be good to have something built into the language that allows a package author to make clear what is public/internal.

[c42f]

Valid gripe! I actually started writing a julep on internal fields, but I'm not sure it was going in the right direction (and also it's hard to get any feedback on these kind of things)

https://github.com/JuliaLang/Juleps/pull/54