aardappel / lobster

The Lobster Programming Language

Home Page:http://strlen.com/lobster

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Crash with call to qsort_in_place on array of structs

MortimerSnerd opened this issue · comments

Windows 10. Got the latest commit today. It's not crashing at runtime, but compile time. Here's the log:

===== Crash Log =====
Date: 2022-04-07, Time: 23:42:47
CMD: lobster-release test.lobster 
ExpCode: 0xE06D7363, ExpFlags: 1, ExpAddress: 0xFE574B59
SymInit: Symbol-SearchPath: '.;C:\src;C:\src\lobster\bin;C:\Windows;C:\Windows\system32;SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols;', symOptions: 530, UserName: 'pkelley'
OS-Version: 6.2.9200 () 0x300-0x1
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FFEFE574B59)
00007FFEFE574B59 (KERNELBASE): (filename not available): RaiseException
d:\a01\_work\20\s\src\vctools\crt\vcruntime\src\eh\throw.cpp (75): _CxxThrowException
d:\a01\_work\20\s\src\vctools\crt\github\stl\src\xthrow.cpp (21): std::_Xlength_error
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\include\vector (1724): std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::_Xlength
C:\src\lobster\dev\src\lobster\codegen.h (401): lobster::CodeGen::GenUnwind
C:\src\lobster\dev\src\lobster\codegen.h (450): lobster::CodeGen::GenCall
C:\src\lobster\dev\src\lobster\codegen.h (1290): lobster::Block::Generate
C:\src\lobster\dev\src\lobster\codegen.h (1379): lobster::IfThen::Generate
C:\src\lobster\dev\src\lobster\codegen.h (1738): lobster::Return::Generate
C:\src\lobster\dev\src\lobster\codegen.h (352): lobster::CodeGen::GenScope
C:\src\lobster\dev\src\lobster\codegen.h (261): lobster::CodeGen::CodeGen
C:\src\lobster\dev\src\compiler.cpp (323): lobster::Compile
C:\src\lobster\dev\src\main.cpp (190): SDL_main
C:\src\lobster\dev\external\SDL\src\main\windows\SDL_windows_main.c (177): main_getcmdline
d:\a01\_work\20\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (288): __scrt_common_main_seh
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FFEFF407034)
00007FFEFF407034 (KERNEL32): (filename not available): BaseThreadInitThunk
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FFF00802651)
00007FFF00802651 (ntdll): (filename not available): RtlUserThreadStart

And here's an example that reproduces it:

import std

struct pair<A,B>:
   first: A
   second: B

def someproc(x: [pair<int,int>]):
   qsort_in_place(x) a, b: return a.first < b.first

let ps = map(5): pair<int,int>{1, 2}
someproc(ps)

I messed up, I've got a return in the body of the qsort_in_place. I did it in the original code, and the reproduction. So that's my mistake, it may be new that it makes the compiler crash.

Should be fixed for now in 54e1bc2

I agree that accidentally writing return in those kinds of places will give surprising results, but I also don't know how to improve it.

We can't allow an actual return there since that would a) require special syntax for non local returns, and b) remove the "control structure" feel of these calls, and c) make everything more verbose.

It's also not easy to detect/warn that in this case it is non-sensical, because there are similar cases where you do want to do this. In this case the inner function gets called from with a for loop inside qsort_in_place, and it does not make sense you'd want to unconditionally exit it. But if it was an if, it would make sense. So that would come down to "heuristics" which isn't a great basis for a language feature.