crystal tool unreachable doesn't seem to work with a default Lucky app out of the box
#14034
Comments
jwoertink
added
the
kind:bug
|
Looks like this is probably related to #13879 I just tried against master and got a stack overflow |
|
Hello, I stumbled upon this issue while looking for a similar one, and I wanted to let you know that the same problem happens also with Here's an example with the Lucky Clover tutorial: |
|
That's very helpful information. If all those tools are affected, it might be an error in the compiler when configured to build without codegen. I don't expect that to have any effect on the semantic stage, though 😕 |
|
Thanks a lot for having a look at it already. I just pushed my code here: https://github.com/cippaciong/lucky-clover-tutorial You should be able to reproduce it with one of my examples above: |
|
So with that repo I'm getting an error that's seemingly introduced by some macro: Reproduction steps: git clone https://github.com/cippaciong/lucky-clover-tutorial
cd lucky-clover-tutorial
shards install
crystal tool implementations -c src/pages/fortunes/index_page.cr:2:20 src/app.cr |
|
You may need to run |
|
@straight-shoota I removed |
|
A non-release compiler has some more valuable debug info: $ crystal tool implementations -c src/pages/fortunes/index_page.cr:2:20 src/app.cr
Using compiled compiler at /home/johannes/src/crystal-lang/crystal/.build/crystal
Stack overflow (e.g., infinite or very deep recursion)
[0x55cdf7250eb6] *Exception::CallStack::print_backtrace:Nil +118 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf7226946] ~procProc(Int32, Pointer(LibC::SiginfoT), Pointer(Void), Nil) +310 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x7fbe7751a520] ?? +140456022353184 in /lib/x86_64-linux-gnu/libc.so.6
[0x55cdf88c5c37] *Crystal::ImplementationsVisitor +7 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf88c5f04] *Crystal::ImplementationsVisitor +724 in /home/johannes/src/crystal-lang/crystal/.build/crystal (7695 times)
[0x55cdf88c590a] *Crystal::ImplementationsVisitor +506 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf88c56a6] *Crystal::ImplementationsVisitor +54 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf88c549a] *Crystal::ImplementationsVisitor#process<Crystal::Compiler::Result>:Crystal::ImplementationResult +74 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf87be982] *Crystal::Command#implementations:Nil +1650 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf87b6ee0] *Crystal::Command#tool:(Bool | Nil) +624 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf87ae749] *Crystal::Command#run:(Bool | Crystal::Repl::Value | Nil) +1865 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf87ade4b] *Crystal::Command::run<Array(String)>:(Bool | Crystal::Repl::Value | Nil) +43 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf87addbe] *Crystal::Command::run:(Bool | Crystal::Repl::Value | Nil) +46 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf719b160] __crystal_main +2736 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf7448513] *Crystal::main_user_code<Int32, Pointer(Pointer(UInt8))>:Nil +19 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf744847a] *Crystal::main<Int32, Pointer(Pointer(UInt8))>:Int32 +58 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x55cdf71a8736] main +6 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x7fbe77501d90] ?? +140456022252944 in /lib/x86_64-linux-gnu/libc.so.6
[0x7fbe77501e40] __libc_start_main +128 in /lib/x86_64-linux-gnu/libc.so.6
[0x55cdf719a5e5] _start +37 in /home/johannes/src/crystal-lang/crystal/.build/crystal
[0x0] ??? |
|
@straight-shoota hmm interesting but I didn't get if I should already be able to infer anything from that. Did it give you a clue of what might be the issue here? To me it's pretty unintelligible unfortunately. |
|
No, I got no clue from that. I tried to dig a bit more, but didn't get far. Just left that comment to have a trail for further analysis as it has a bit more information than the previous traces. |
|
We can reduce the code base to make the clue more clearly. |
|
From a quick look I did this seems to be originating from: crystal/src/compiler/crystal/tools/unreachable.cr Lines 135 to 137 in 1f6b51d Here's some information and how you can see the loop. type # => Bool::Lucky
type.class # => Crystal::NonGenericModuleType
type.types? # => {"ColumnType" => Bool::Lucky::ColumnType,
"Criteria" => Bool::Lucky::Criteria(T, V)}
type # => Bool::Lucky::ColumnType
type.class # => Crystal::AliasType
type.types? # => {"Lucky" => Bool::Lucky}
type # => Bool::Lucky
type.class # => Crystal::NonGenericModuleType
type.types? # => {"ColumnType" => Bool::Lucky::ColumnType,
"Criteria" => Bool::Lucky::Criteria(T, V)}
type # => Bool::Lucky::ColumnType
type.class # => Crystal::AliasType
type.types? # => {"Lucky" => Bool::Lucky}Ultimately was able to reduce it down to: struct Bool
module Lucky
alias ColumnType = Bool
end
endWhich produces: Stack overflow (e.g., infinite or very deep recursion)
[0x5c93e8d22576] *Exception::CallStack::print_backtrace:Nil +118 in /home/george/dev/git/crystal/.build/crystal
[0x5c93e8cecf36] ~procProc(Int32, Pointer(LibC::SiginfoT), Pointer(Void), Nil) +310 in /home/george/dev/git/crystal/.build/crystal
[0x706ea475d1d0] ?? +123620507898320 in /usr/lib/libc.so.6
[0x5c93ea123687] *Crystal::UnreachableVisitor#process_type<Crystal::NamedType+>:Nil +7 in /home/george/dev/git/crystal/.build/crystal
[0x5c93ea1238ca] *Crystal::UnreachableVisitor#process_type<Crystal::NamedType+>:Nil +586 in /home/george/dev/git/crystal/.build/crystal (32729 times)
[0x5c93ea123042] *Crystal::UnreachableVisitor#process_type<Crystal::Program>:Nil +450 in /home/george/dev/git/crystal/.build/crystal
[0x5c93ea12221f] *Crystal::UnreachableVisitor#process<Crystal::Compiler::Result>:Array(Tuple(Crystal::Def+, Int32)) +79 in /home/george/dev/git/crystal/.build/crystal
[0x5c93ea00e8e7] *Crystal::Command#unreachable:Nil +2327 in /home/george/dev/git/crystal/.build/crystal
[0x5c93ea005dcc] *Crystal::Command#tool:(Bool | Nil) +732 in /home/george/dev/git/crystal/.build/crystal
[0x5c93e9ffdc88] *Crystal::Command#run:(Bool | Nil) +1480 in /home/george/dev/git/crystal/.build/crystal
[0x5c93e9ffd559] *Crystal::Command::run<Array(String)>:(Bool | Nil) +25 in /home/george/dev/git/crystal/.build/crystal
[0x5c93e9ffd51d] *Crystal::Command::run:(Bool | Nil) +29 in /home/george/dev/git/crystal/.build/crystal
[0x5c93e8c6e4d9] __crystal_main +2601 in /home/george/dev/git/crystal/.build/crystal
[0x5c93e8e64e46] *Crystal::main_user_code<Int32, Pointer(Pointer(UInt8))>:Nil +6 in /home/george/dev/git/crystal/.build/crystal
[0x5c93e8e64dba] *Crystal::main<Int32, Pointer(Pointer(UInt8))>:Int32 +58 in /home/george/dev/git/crystal/.build/crystal
[0x5c93e8c7bb96] main +6 in /home/george/dev/git/crystal/.build/crystal
[0x706ea4745e08] ?? +123620507803144 in /usr/lib/libc.so.6
[0x706ea4745ecc] __libc_start_main +140 in /usr/lib/libc.so.6
[0x5c93e8c6d9d5] _start +37 in /home/george/dev/git/crystal/.build/crystal
[0x0] ???IDK how to really fix this, but I'd wager a guess you could avoid it by not monkey patching stdlib types like this 🤷. EDIT: I think what's going on is compiler sees struct Bool
module ::Lucky
alias ColumnType = ::Bool
end
endSo it's definitely related to foreign things being within the stdlib type, tho TBD on if there's a fix, or the fix is just don't do this. EDIT2: Not specific to stdlib types, seems more so it's just a circular reference that can happen when an alias defined within a type references that type itself: struct Foo
alias ColumnType = Foo
end |
|
@Blacksmoke16 That's a great find! 🕵️
The latter is easier and more efficient. We have no use of processing type aliases, so skipping them is completely fine. |
When I generate a brand new Lucky app, then try to run this command, I get this error
The text was updated successfully, but these errors were encountered: