Fix #204 — calling methods on null receiver does not crash

[TobiasWrigstad]

This PR adds an additional branch before each method call or message send in Encore. Basically

x.m() 

is turned into (mock C code):

if (x) { x.m(); } else { fprintf(stderr, "error message"); abort() }

An error message looks like this

Error: empty receiver in x ! test(...) in "src/tests/encore/basic/recvNullSend.enc" (line 8, column 9)

using ! or . appropriately.

The reason to add the branch at the call-site rather than at the beginning of each method was because;

1. non-null types will be able to avoid this check, but this cannot be done inside the method
2. the C compiler will be able to elide redundant checks and be smart about optimising

Note that the tests are written with PR 481 in mind. Without this PR, there is no support for testing this PR.

[albertnetymk]

I thinking moving the macro in Header.hs to encore.h would make it more readable.

[TobiasWrigstad]

@albertnetymk DONE

[TobiasWrigstad]

@albertnetymk bump!

[albertnetymk]

This PR is could be merged after #481.

Some nitpicking:

• targetNullCheck is defined almost identically in two places, which could be leveled up so that it could be used in both clauses. Sth like:

targetNullCheck "." ntarget target name meta = ...
targetNullCheck "!" ntarget target name meta = ...

• this PR exceeds 80 line width in some places

[TobiasWrigstad]

@albertnetymk I hope I have addressed both points now.

[albertnetymk]

Looks great. Can be merged after #481

[TobiasWrigstad]

@albertnetymk FYI #481 is now merged.

[albertnetymk]

The two added tests fail for me, sth like:

     | ERROR: test encore/basic/recvNullCall failed with output:
     | vvv OUTPUT vvvvvvvvvvvvvvvvv
     | Error: empty receiver in x.test(...) in "recvNullCall.enc" (line 8, column 7)
     | vvv EXPECTED vvvvvvvvvvvvvvv
     | Error: empty receiver in x.test(...) in "src/tests/encore/basic/recvNullCall.enc" (line 8, column 7)

[TobiasWrigstad]

And to be sure — did you update to support #481 first?

[albertnetymk]

Think so. Just need to pull dev, nothing else, right?

[TobiasWrigstad]

I'll investigate. The programs are expected to fail but that should be counted as passing tests.

[TobiasWrigstad]

I believe something may have changed in the mean time causing the error output of the failing tests to change, which made the .err file not match. Fixed now IMO. Please try again.

[TobiasWrigstad]

@albertnetymk bump

[albertnetymk]

Sorry for the delay. dev was broken when I tried this PR this morning.

Tried the HEAD~ with this PR, and it works OK. Merging now.