Mysterious internal error when using Grassmann.jl

[MasonProtter]

Hi, I encountered a mysterious internal using the Grassmann.jl package which I reproduced on a fresh Julia build from master.

julia> using Grassmann
[ Info: Precompiling Grassmann [4df31cd9-4c27-5bea-88d0-e6a7146666d8]

julia> basis"+++"
(⟨+++⟩, v, v₁, v₂, v₃, v₁₂, v₁₃, v₂₃, v₁₂₃)

julia> 1 + v1 + v2
Internal error: encountered unexpected error in runtime:
MethodError(f=typeof(Base.string)(), args=(Expr(:call, Symbol("!"), Expr(:., :typ, :(:mutable))),), world=0x0000000000000ecd)
rec_backtrace at /Users/mason/juliabuild/julia/src/stackwalk.c:94
record_backtrace at /Users/mason/juliabuild/julia/src/task.c:217
jl_throw at /Users/mason/juliabuild/julia/src/task.c:417
jl_method_error_bare at /Users/mason/juliabuild/julia/src/gf.c:1679
jl_method_error at /Users/mason/juliabuild/julia/src/gf.c:1697
jl_lookup_generic_ at /Users/mason/juliabuild/julia/src/gf.c:2226
jl_apply_generic at /Users/mason/juliabuild/julia/src/gf.c:2246
lift_leaves at ./compiler/ssair/passes.jl:300
getfield_elim_pass! at ./compiler/ssair/passes.jl:660
run_passes at ./compiler/ssair/driver.jl:121
optimize at ./compiler/optimize.jl:167
typeinf at ./compiler/typeinfer.jl:33
typeinf_ext at ./compiler/typeinfer.jl:586
typeinf_ext at ./compiler/typeinfer.jl:623
jfptr_typeinf_ext_1 at /Users/mason/juliabuild/julia/usr/lib/julia/sys.dylib (unknown line)
jl_apply_generic at /Users/mason/juliabuild/julia/src/gf.c:2250 [inlined]
jl_apply at /Users/mason/juliabuild/julia/src/./julia.h:1594 [inlined]
jl_type_infer at /Users/mason/juliabuild/julia/src/gf.c:254
jl_compile_method_internal at /Users/mason/juliabuild/julia/src/gf.c:1850
jl_fptr_trampoline at /Users/mason/juliabuild/julia/src/gf.c:1894
do_call at /Users/mason/juliabuild/julia/src/interpreter.c:323
eval_stmt_value at /Users/mason/juliabuild/julia/src/interpreter.c:362 [inlined]
eval_body at /Users/mason/juliabuild/julia/src/interpreter.c:758
jl_interpret_toplevel_thunk_callback at /Users/mason/juliabuild/julia/src/interpreter.c:884
Interpreter frame (ip: 0)
Core.CodeInfo(code=Array{Any, (2,)}[
  Expr(:call, :+, 1, :v1, :v2),
  Expr(:return, SSAValue(1))], codelocs=Array{Int32, (2,)}[1, 1], ssavaluetypes=2, ssaflags=Array{UInt8, (0,)}[], method_for_inference_limit_heuristics=nothing, linetable=Array{Any, (1,)}[Core.LineInfoNode(method=Symbol("top-level scope"), file=Symbol("REPL[4]"), line=1, inlined_at=0)], slotnames=Array{Any, (0,)}[], slotflags=Array{UInt8, (0,)}[], slottypes=nothing, rettype=Any, parent=nothing, min_world=0, max_world=0, inferred=false, inlineable=false, propagate_inbounds=false, pure=false)jl_interpret_toplevel_thunk at /Users/mason/juliabuild/julia/src/interpreter.c:893
jl_toplevel_eval_flex at /Users/mason/juliabuild/julia/src/toplevel.c:797
jl_toplevel_eval_flex at /Users/mason/juliabuild/julia/src/toplevel.c:746
jl_toplevel_eval at /Users/mason/juliabuild/julia/src/toplevel.c:806 [inlined]
jl_toplevel_eval_in at /Users/mason/juliabuild/julia/src/toplevel.c:826
eval at ./boot.jl:327
eval_user_input at /Users/mason/juliabuild/julia/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:86
macro expansion at /Users/mason/juliabuild/julia/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:118 [inlined]
#26 at ./task.jl:261
jl_apply at /Users/mason/juliabuild/julia/src/./julia.h:1594 [inlined]
start_task at /Users/mason/juliabuild/julia/src/task.c:572
1 + 1v₁ + 1v₂

I initially thought it could be the flagrant use of @pure in the package but Keno said he thought that was unlikely so I am opening an issue here in case anyone wants to investigate.

---

The issue I opened in the package repo may be found here:
chakravala/Grassmann.jl#7

[MasonProtter]

Okay, so I cloned the repository and removed all uses of @pure (https://github.com/MasonProtter/Grassmann.jl/commit/54f7a7ff0b08458f5e2de91b56fd865bbabb2c2c) and that now I don't run into that particular problem so I think it likely was just a misused @pure causing it.

[chakravala]

As I mentioned in chakravala/Grassmann.jl#7, it is likely there is some mistaken application of @pure in my code somewhere, and it would help to have it narrowed down further. I'm not sure if there would be anything on the Julia language side to resolve this problem though, but I wouldn't know.

[chakravala]

By the way, I have resolved the issue and I am still not entirely sure what caused it, but I think it may have had to do with a conversion step where an object was converted to Any type.

chakravala/Grassmann.jl@1edc6b5#diff-14ec4603ede9d71d995fd5f162284c55L298

This is the critical line of code I had to fix to resolve some other bugs I had, and afterwards the other issue's error cited in #7 has now been resolved also.

[KristofferC]

The abuse of @pure in the code makes it hard to determine if there was a real issue here or not, closing until a repro without @pure is shown.

[vtjnash]

Agreed. Upon reviewing the stacktrace, this code path here should be nearly unreachable except if you have @pure in the code, which easily causes inference to make this erroneous deduction.