pre/postcondition failures: make the output of interpreter/C backend match

[maxteufel]

this is what the interpreter tells you

$FUZION/lib/wrapping_integer.fz:89:12: error 1: Precondition does not hold
      debug: !overflowOnAdd(other),
-----------^
For call to wrapping_integer.infix +
Call stack:
fib.#loop0: -:4:17:
      next := a + b
----------------^
fib.#loop0: -:2:3:
  for a u128 := 0.as_u128, b
--^
...  repeated 183 times  ...

fib: -:2:3:
  for a u128 := 0.as_u128, b
--^
#loop1: -:10:18:
  say "fib $i = {fib i}"
-----------------^
#loop1: -:9:1:
for i in 0.. : 50 do
^
...  repeated 3 times  ...

#universe: -:9:1:
for i in 0.. : 50 do
^

*** fatal errors encountered, stopping.

vs the C backend

*** failed pre-condition on call to 'u128.infix +'

this should eventually match. maybe we can wait for Java bytecode backend, but its & the C executable output should match.

The interpreter's output seems to be too verbose, the C executable does not even tell you where in the code the error happened.

[fridis]

Several steps (that I have in the back of my head since a while) would lead to this:

• a failed pre- or postcondition should be an operation in an effect (such that this situation could be handled within fuzion code)
• there should be an API to get the current call trace, not only in case of an error but in any case. This would be useful for all sorts of debugging, performance analysis, etc.
• then, the default effect for pre- / postcondition failures could print a stack trace
• next, if there was an intrinsic to access the source code, this effect could even print the source code positions and be as verbose as the interpreter's output

Does this make sense?

Nevertheless, I do not consider this a bug but an enhancement. Stack trace information should allow some flexibility for the implementation, otherwise important optimizations could not be done.