Closed maleadt closed 1 year ago
This seems to be an issue with the hooks rather than the parser. But definitely a bug, and it's still current - thanks for reporting it :heart:
You can just do JuliaSyntax.enable_in_core!()
to use the version you've got checked out as the default parser. I'll add that to the howto section in the docs I guess. Or maybe the readme... it's hard to know which parts to put where.
Minimal reproduction:
julia> JuliaSyntax.core_parser_hook("x var\"y\"", "foo.jl", 0, :all)
┌ Error: JuliaSyntax parser failed — falling back to flisp!
│ exception =
│ Internal error: length(args) == 1
│ Stacktrace:
│ [1] error(::String, ::String)
│ @ Base ./error.jl:44
│ [2] internal_error(strs::String)
│ @ JuliaSyntax ~/.julia/dev/JuliaSyntax/src/utils.jl:23
│ [3] _internal_node_to_Expr(source::SourceFile, srcrange::UnitRange{Int64}, head::JuliaSyntax.SyntaxHead, childranges::Vector{UnitRange{Int64}}, childheads::Vector{JuliaSyntax.SyntaxHead}, args::Vector{Any})
│ @ JuliaSyntax ~/.julia/dev/JuliaSyntax/src/expr.jl:200
│ [4] _to_expr(node::SyntaxNode)
│ @ JuliaSyntax ~/.julia/dev/JuliaSyntax/src/expr.jl:524
│ [5] _to_expr(node::SyntaxNode) (repeats 2 times)
│ @ JuliaSyntax ~/.julia/dev/JuliaSyntax/src/expr.jl:523
│ [6] Expr(node::SyntaxNode)
│ @ JuliaSyntax ~/.julia/dev/JuliaSyntax/src/expr.jl:528
│ [7] core_parser_hook(code::String, filename::String, lineno::Int64, offset::Int64, options::Symbol)
│ @ JuliaSyntax ~/.julia/dev/JuliaSyntax/src/hooks.jl:209
│ [8] core_parser_hook(code::String, filename::String, offset::Int64, options::Symbol)
│ @ JuliaSyntax ~/.julia/dev/JuliaSyntax/src/hooks.jl:271
│ [9] top-level scope
│ @ REPL[22]:1
│ [10] eval
│ @ ./boot.jl:370 [inlined]
│ [11] eval_user_input(ast::Any, backend::REPL.REPLBackend, mod::Module)
│ @ REPL ~/.julia/juliaup/julia-1.9.2+0.x64.linux.gnu/share/julia/stdlib/v1.9/REPL/src/REPL.jl:153
│ [12] repl_backend_loop(backend::REPL.REPLBackend, get_module::Function)
│ @ REPL ~/.julia/juliaup/julia-1.9.2+0.x64.linux.gnu/share/julia/stdlib/v1.9/REPL/src/REPL.jl:249
│ [13] start_repl_backend(backend::REPL.REPLBackend, consumer::Any; get_module::Function)
│ @ REPL ~/.julia/juliaup/julia-1.9.2+0.x64.linux.gnu/share/julia/stdlib/v1.9/REPL/src/REPL.jl:234
│ [14] run_repl(repl::REPL.AbstractREPL, consumer::Any; backend_on_current_task::Bool, backend::Any)
│ @ REPL ~/.julia/juliaup/julia-1.9.2+0.x64.linux.gnu/share/julia/stdlib/v1.9/REPL/src/REPL.jl:379
│ [15] run_repl(repl::REPL.AbstractREPL, consumer::Any)
│ @ REPL ~/.julia/juliaup/julia-1.9.2+0.x64.linux.gnu/share/julia/stdlib/v1.9/REPL/src/REPL.jl:365
│ [16] (::Base.var"#1017#1019"{Bool, Bool, Bool})(REPL::Module)
│ @ Base ./client.jl:421
│ [17] #invokelatest#2
│ @ ./essentials.jl:816 [inlined]
│ [18] invokelatest
│ @ ./essentials.jl:813 [inlined]
│ [19] run_main_repl(interactive::Bool, quiet::Bool, banner::Bool, history_file::Bool, color_set::Bool)
│ @ Base ./client.jl:405
│ [20] exec_options(opts::Base.JLOptions)
│ @ Base ./client.jl:322
│ [21] _start()
│ @ Base ./client.jl:522
│ offset = 0
│ code = "x var\"y\""
└ @ JuliaSyntax ~/.julia/dev/JuliaSyntax/src/hooks.jl:258
Ok. I think what's going on here is that a node/token of type K"var"
with zero children is bumped by the parser during recovery here
When building the tree after parsing
K"var"
which is bump
'ed vs an empty node K"var"
- this is implicit (see here https://github.com/JuliaLang/JuliaSyntax.jl/blob/b941fc083a524a063c53c24a9dad0d3461b85a03/src/parse_stream.jl#L1034)K"var"
without any children breaks the expected invariant that these should have exactly one child.This first point is pretty awkward and if it could be fixed that would be ideal.
I encountered the following internal error on 1.10:
I'm not sure whether this still reproduces on latest JuliaSyntax.jl; maybe it'd be good to add a section to the README how to easily test the latest version of the parser to see if it's worth filing a bug?