Ballerina allows panics to be caught using trap expressions. These are used only for abnormal conditions, such as program bugs, not for normal error handling, so use of trap should be infrequent.

This follows on from #44.

I see three possible implementation strategies:

1. Use something similar to what C++ exceptions does (see #28)
2. Use setjmp/longjmp (this is viable for Ballerina, because, at least for now, we do not have destructors)
3. Use function return values: where a function returns a value with LLVM representation R, the actual return type would be a structure { P, R }, where P can represent a error value or a nil value N, representing the absence of an error; then a normal return R is handled by returning { N, R }, and a panic with associated error E is handled by returning { E, undef }.

C API has

• LLVMAttributeIndex (what the attribute applies to: function, return value or specific parameter)
• LLVMAddAttributeAtIndex
• LLVMCreateStringAttribute
• LLVMCreateEnumAttribute (looks like val argument is typically 0), which needs
  • LLVMGetEnumAttributeKindForName

Description:

Write tests such that it is execute without writing any extra code. Expectation and input should be mentioned in the file itself.
Slimier to LLVM LIT system errors should be mentioned inline.

Add support for:

• br (we need both conditional and unconditional variants) [LLVMBuildBr, LLVMBuildCondBr]
• icmp (strictly speaking we may not need all the possible predicates but I think we can support all similar to how we do binaryInt) [LLVMBuildICmp]
• unreachable (I think this is optional but better if we can add this after calling abort and should be trivial to implement)[LLVMBuildUnreachable]

LLVM defines its sdiv instruction to have undefined behaviour when the right operand is zero. Similarly, when the left operand is INT_MIN and the right operand is -1.

One way to solve this is to generate code that explicitly tests for these cases before using the sdiv instruction. This issue is to investigate whether there is a better way.

At the assembly code level, at least for x86, we would ideally produce a x86 IDIV instruction. This would result in a CPU exception which would the OS would turn into a signal, which we can then catch. Is there a way to make LLVM generate this assembly, that is portable and supported?

Rust has the same semantics for integer division that we do, and uses LLVM, so we should look at how they do it.

We should also look at how Swift does integer division.

There are similar problems with remainder also.

In order to implement the error value #167 and to implement #45, we need not just to print a backtrace as in issue #6, but take a snapshot of the stack, which we can store in the error value and be used subsequently to generate a backtrace.

We want to be as lazy as possible here, i.e. do as little work as possible when taking the snapshot, because the backtrace may never be needed.

What this would mean would be that

• stack unwinding can use the C++ runtime's implementation
• we generate code for Ballerina trap similar to what C++ generates for C++ catch/throw
• Ballerina panics can interop with code in C++ that uses exception handling

Reasons why this might be a good approach:

• one of the implementation strategies that Rust uses for panics is on top of C++ exception/handling
• Ballerina panic/trap semantics are a subset of C++ catch/throw
• C++ exception handling has a well-defined, stable ABI
• LLVM's exception handling is C++ centric: LLVM IR to a large extent just models C++ exception handling semantics
• the C++ ABI's concept of personality function provides a degree of language-specific functionality
• if we use C++ for the native parts of langlib, then our native langlib functions can use C++ throw when they need to panic (see #29)

This is similar to #34 but for non-intrinsic functions. We need it for #16.

Preferably column too.

This requires passing line/column info through the compilation pipeline from parsing to LLVM building.

Description:
If bal file contains a function call, it is considered as potentially panicking instruction and call _bal_panic after return

Steps to reproduce:
ball file:

public function main() {
    int x = foo();
}

function foo() returns int {
    return 2;
}

generated llvm for the main function:

define void @_B_main () {
  %R0 = alloca i64, align 8
  %R1 = alloca i64, align 8
  %R2 = alloca i64, align 8
  %R3 = call i64 @_B_foo ()
  store i64 %R3, i64* %R0, align 8
  %R4 = load i64, i64* %R0, align 8
  store i64 %R4, i64* %R1, align 8
  ret void ; below thress line are not executed
  %R5 = load i64, i64* %R2, align 8 
  call void @_bal_panic (i64 %R5)
  unreachable
}```

Need:

• Equal
• IntCompare
• IntNegate
• Branch
• CondBranch
• BooleanNot

We will deal with panicking separately.

We should serialize SymType to a pseudo-Ballerina text format with possible addition of not operator.
Since SemTypes have references to TypeCheckContext we can't trivially serialize it. Some type references may be needed.

Prerequisite for #15.

We need eventually to have full debugging information. But to start we should have just enough to enable us to get line numbers in backtraces (see #6).

Description:
Running the command bal test --tests "testCompile*" ../compiler says that two tests are failing.

		[fail] testCompileError:

		    wrong error position /home/kavindu/WSO2-GIT/nbal/nballerina/tests/../tests/Eassign01.bal
		    	
		    	expected: <int> '4'
		    	actual	: <()> ''

		    	at ballerina.test.0_8_0:createBallerinaError(assert.bal:43)
		    	ballerina.test.0_8_0:assertEquals(assert.bal:75)
		    	wso2.nballerina.0_1_0.tests.integration:testCompileError(tests/integration.bal:33)

		[fail] testCompileError:

		    wrong error position /home/kavindu/WSO2-GIT/nbal/nballerina/tests/../tests/Eassign00.bal
		    	
		    	expected: <int> '4'
		    	actual	: <()> ''

		    	at ballerina.test.0_8_0:createBallerinaError(assert.bal:43)
		    	ballerina.test.0_8_0:assertEquals(assert.bal:75)
		    	wso2.nballerina.0_1_0.tests.integration:testCompileError(tests/integration.bal:33)

Also running script (sh testll.sh) says,

Aborted (core dumped)
Aborted (core dumped)
Aborted (core dumped)
Aborted (core dumped)

Steps to reproduce:

bal test --tests "testCompile*" ../compiler
sh testll.sh

We need a full set of test cases for subset 1, using the format described in #12 (comment)

These test cases must follow the on the definition of correctness and the definition of subset 1.

If stuff doesn't work yet, we can commit the cases as failing cases.

The semantic E cases will need #39 to work.

Build LLVM br/condBr from BIR branch/condBranch.

Add llvm constructs needed to support integer operations.

Ref:
https://github.com/ruvi-d/nballerina-tests/tree/master/stage_1

This is follow on from #55 and goes with #56.

When we tag subset 1, we should be in a consistent state.

These correspond to local variables, so there's an obvious semantic.

Follow on from #55.

This is the part leftover from #5.

Add support for:

• Define structure types (minimally {i64, i1}) and use them as a type of a value / return type of function
• Use extractvalue so we can get values out of them by index

The parsing tests should be designed in a way that when the AST data structure is changed, it is only a little work to get the tests working.

The front-end generates BIR that allows for integer arithmetic instructions to panic on overflow or division by zero. We need to support this in the backend.

There are two parts to the design of this:

1. how do we detect overflow/division by zero?
2. what do we do when we have detected this?

For part 1, there are two subcases:

• add, sub, mul: in these cases, we use the intrinsics provided by LLVM
• div, rem: in this cases, we explicitly test whether the operands would overflow or divide by zero (this is the conclusion of issue #38)

For part 2, I think the best solution for subset 1 is to call a runtime function passing it the source location that caused the panic and a code for the type of panic (overflow vs division by zero); this runtime function will print out a message with the location and terminate the program.

The parser being developed in #23 includes support for break and continue. The flow control implemented in BIR is sufficient for these. But codeGen does not yet handle it. We need somehow to pass down into statement codeGen the labels to which break and continue should jump.

See the docs in #11

Description:
Serialize BIR format to a text format and incorporate that into the testing.

First step for subset 2 is to decide what it is.

I have created a doc to describe the possibilities.

I think fastcc is needed.

Currently the root of the repo is the ballerina package containing the compiler.

But nballerina will need other parts, in particular a runtime, that are tightly integrated with the compiler.

My current thinking is:

• make the current root directory become a subdirectory compiler
• rename the package module from nballerina to nballerina.compiler
• add runtime directory for the runtime
• use CMake to build everything: CMake will run bal to build the compiler package
• add tests directory to test the compiler together with runtime (when a program is compiled and executed, does it produce the right result)
• add docs directory for project documentation

Add annotation support for nback.llvm

Global identifiers in Ballerina are structured values with at least organization/module/name (not sure about version). We need to encode this into a symbol that can go in an object file.

The backtrace code #6 needs to demangle.

We can call intrinsics using a call instruction like other functions. But we also need to create a Function that refers to them. The nback.llvm module should take care of emitting the appropriate declaration.

LLVM C API has:

• LLVMGetIntrinsicDeclaration
• LLVMLookupIntrinsicID

We may need two types of Function.

This is needed in order to be able to use #24 to support arithmetic with overflow.

When we do #17, it would also be good if we use an alternative module to nback.llvm that calls the LLVM C API via JNI.

We can use this to do it:

https://github.com/bytedeco/javacpp-presets/tree/master/llvm

This will validate that when we self-host we will be able to easily switch to the C API.

Description:
$subject. It seems there are two extra load and store instruction which are not needed.

Steps to reproduce:
bal file:

public function main() {
    int x = foo();
}

function foo() returns int {
    return 2;
}

llvm ir for the main function:

define void @_B_main () {
  %R0 = alloca i64, align 8
  %R1 = alloca i64, align 8
  %R2 = call i64 @_B_foo ()
  store i64 %R2, i64* %R0, align 8

  ; these two instructions are not needed.
  %R3 = load i64, i64* %R0, align 8
  store i64 %R3, i64* %R1, align 8

  ret void
}
define internal i64 @_B_foo () {
  ret i64 2
}

This can be verified by generating a llvm ir for a similar C code.

Hardcode a partial implementation of io:println (just accepting a single int argument), so we can do #12

This builds on #28.

The idea would be to use a carefully chosen, very small subset of C++. In particular, all Ballerina values would be represented by what C++11 calls standard-layout classes: these are basically POD structs that have the same layout as equivalent C structs (so no virtual functions, no destructors).

Compared to C, this gives us a number of useful features.

First, we have inheritance. I can say

struct Header {
  int gc_header;
};

struct String : Header {
   int length;
  // bytes go here
};

Second, we can use C++ throw (building on #28).

Third, we can use C++ templates to provide separate per-representation implementations of Ballerina structures, particularly arrays.

Fourth, we can use C++ classes to implement a wrapper around pointers into the garbage-collected heap; the goal of the wrapper would be to ensure that the collector can find all the roots that are in C++ stack frames.

Compared to C, there is one important thing that we loose: variable length structures, e.g.

struct String {
   int length;
   char[] data;
};

There's a stub that needs to be implemented.

Ballerina requires that the / operator result a panic if its right operand is 0. We could handle this by explicitly testing for 0, before performing the division, but it would be much more efficient if instead we relied on the CPU's ability to generate an exception in this case. In POSIX terms, the CPU exception will turn into a signal (SIGFPE in this case), which the kernel will deliver to the program. Using sigaction we can catch this exception and get the address (in siginfo.si_addr) of the instruction that caused CPU exception. We should then be able to use this to print a backtrace.

Description:
Have jBallerina compiler call into compiled version of nBallerina with a BIR object.

Eventually panics need to unwind until they are caught with trap, but until then our implementation of panic can simply print a backtrace before exiting.

This needs some debug info (#7), and is an enhancement to the strategy in #44, which explicitly passes the location of the offending instruction to the runtime panic function.

At the moment, compiling the .ll file generated by the compiler produces the warning:

warning: overriding the module target triple with x86_64-pc-linux-gnu [-Woverride-module]

We need to generate the appropriate target triple to deal with this.

This should be a configurable value. Eventually, it should be possible to override with command-line option.

Implement enough of a verifier to catch semantics errors in subset 1. At least:

• in function call, number of arguments must match signature of called function
• in function call, type of arguments must match signature of called function
• integer binary operations only on int not boolean
• == and != must have non-empty intersection
• integer minus only on int not boolean
• logical ! only on boolean not int
• condition of if/else/while is boolean
• return statement must return value that matches return type of signature
• types in assignment

Maybe more...

Make sure we have tests for

• function with non-nil return value in call statement
• function with nil return value in expression

Create a .md file in this repo describing the precise subset we are targeting.

Full mangling #14 is quite complicated.

For subset 1, something much simpler will suffice.

Description:
$subject

Steps to reproduce:
bal file for main function:

public function main() {
    int x = 3;
    if (x == 3) {
        bar(100);
    } 
}

llvm ir for the main function:

define void @_B_main () {
  %R0 = alloca i64, align 8
  %R1 = alloca i1, align 8
  %R2 = alloca i1, align 8
  store i64 3, i64* %R0, align 8
  %R3 = load i64, i64* %R0, align 8
  %R4 = icmp eq i64 %R3, 3
  store i1 %R4, i1* %R1, align 8
  %R5 = load i1, i1* %R1, align 8
  br i1 %R5, label %L1, label %L2
L1:
  call void @_B_bar (i64 100)
  store i1 0, i1* %R2, align 8 ; This is an extra instruction
  br label %L2
L2:
  ret void
}

Need to change our minimal runtime to call mangled main.

This needs a minimal amount of mangling #14

Add following test case as Pstackoverflow00.bal

public function main() {
    f(); // @panic
}

function f() {
    f();
}

Should be on all methods where corresponding LLVM function has it.