The following code crashes without linenumber on Nim Compiler Version 0.18.1 [Windows: amd64]; Compiled at 2018-07-14; git hash: 332469692d5053c6c935163e196b117b6979c8e7
proc test(): string =
result = nil & ""
with
Error: unhandled exception: false ast.nim(1606) getStrOrChar [AssertionError]
Maybe a better error message is sufficient here.
If I'm not mistaken, @Araq changed nil's semantics.
To verify what I'm saying, you can test it with the following code:
import typetraits
proc `$`*(T: typedesc): string = name(T)
template test(x): typed =
echo "type: ", type(x), ", value: ", x
test nil
You should get the following error message (I'm wrapping it for readability):
tmp.nim(8, 6) Error: ambiguous call; both
system.$(s: WideCString)[declared in lib/system/widestrs.nim(167, 5)] and
system.$(x: seq[T])[declared in lib/system.nim(2561, 5)] match for: (nil)
@Araq, by the way is this considered a bug or an expected behavior?
Yes, it was/will be changed. But this code wasn't a try to concatenate nil with a string, instead I wanted to show a situation where compiler crashes without line number. These crashes without linenumber are very bad and force the developer to search the bug on his own...
Ah yes, you are completely right. How come I have missed that? Indeed that's a very unfortunate situation for the user.
Now fails with
Error: type mismatch: got <nil, string>
I know these crashes without line info are bad but they are not caused by a single reason.
Most helpful comment
Now fails with
I know these crashes without line info are bad but they are not caused by a single reason.