Implementation of union-type-descriptor

[KavinduZoysa]

This discussion is open to finalize the design on union-type-descriptor implementation. I have presented a couple of bal codes, BIRs and expected shapes of LLVM IR. If I am wrong on the expected shapes of LLVM IR, please correct me.

ex : 1

public function main() {
    int|string u; 
}

public main function() -> () {
    %0(RETURN) ();
    %0(RETURN) ();
    %1(LOCAL) int | string;
    ...
}

In this case, since there is not a variable initialization we can simply represent u in LLVM-IR as i64* size variable.

ex : 2

public function main() {
    int|string u = 2; 
}

public main function() -> () {
    %0(RETURN) ();
    %0(RETURN) ();
    %1(LOCAL) int | string;
    %3(TEMP) int;

    bb0 {
        %3 = ConstLoad 2;
        %1 = <int | string> %3;
        %0 = ConstLoad 0;
        GOTO bb2;
    }
    ...
}

In this case, we have to do the type checking on the rust side(we need to send member types as destination type and type of 3% as source type) and should return a value of i64*.

ex : 3

public function main() {
    int|string u = 2;
    int i = <int> u;
}

public main function() -> () {
    %0(RETURN) ();
    %0(RETURN) ();
    %1(LOCAL) int | string;
    %3(TEMP) int;
    %4(LOCAL) int;

    bb0 {
        %3 = ConstLoad 2;
        %1 = <int | string> %3;
        %4 = <int> %1;
        %0 = ConstLoad 0;
        GOTO bb2;
    }
    ...
}

In this case, we have to do the type checking twice.

1. between int or string member types and value of %3.
2. between int and value of %1.

Highly appreciated your feedback in order to proceed with the implementations.

[manuranga]

In ex 2, we still don't need a type check, since form compile time information we can see casting int to int|string is always successful. what we need is a conversion form int to boxed int.
note that boxed int is not just a pointer to the int.

becase :

1. int current lives on the stack, needs to move it to heap, so it don't get invalidated if we return the union
2. union needs to store runtime type information in the form of 'type string' so we can do the check when we get it out.

[manuranga]

Let's start by checking if source type is a primitive and target type is a union, we know this case is always a "boxing". Additionally we can assert union contains the primitive type, but this will just be a sanity check, since it should alardy be checked by the frontend.

[KavinduZoysa]

Here boxing means doing Box operation is rust side, right?

[manuranga]

No, I mean as a generic term https://en.wikipedia.org/wiki/Object_type_(object-oriented_programming)#Boxing
Rust Box alone is not enough for this, since this box needs to contain the type string as well.

[KavinduZoysa]

Got it, so my plan is,

1. Call Rust when we see <int|string> %3
2. Create a struct in Rust as shown below.

struct UnionResult {
    value, 
    type, 
} // we should discuss the type of each element.

3. Return the boxed pointer to the llvm side.

WDYT?

[manuranga]

This solution looks fine, on it's own. But we have align with how @ramakotareddy is representing array as well.
(eg: type may need to be the first element in the struct.)

[KavinduZoysa]

@ayonam , do you have any suggestions or corrections?

[ayonam]

@KavinduZoysa @manuranga I'm not sure I got this right. Our current method of boxing has the following format:

+-----------------+
| Current TypeStr |
+-----------------+
| Original TypeStr |
+-----------------+
| Data |
+-----------------+

Now, for the Union, say (int | string), I would envisage it as follows:

+-----------------+
| Current TypeStr |
+-----------------+
| Original TypeStr |
+-----------------+
| Integer Value |
+-----------------+
| String Object |
+-----------------+

Now, an assignment operation of an integer to this union will come with a structure like the first one above with the 'Data' being an integer and the Current TypeStr showing an Integer Type as per our name mangling mechanism. Looking at the Current Type of the RHS, the LLVM code should load the Data portion of the RHS and assign it to the "Integer Value" in the structure above. Likewise, if the RHS is a string, it should assign it to the String Object. Here, there will be a typecheck needed before this operation, if the current type shows as "Any". In that case, the Original Type of the RHS and the current type of the LHS (union in this case), should be sent to Rust side for type checking. If the rust side returns true, then the assignment logic mentioned above should be executed.

One more case would be if there is an operation between two such objects. Like say an addition operation. Unless the current type is Any, the front-end would have ensured that the types are matching. But one or both the types are Any, then we should first do a typecheck from the Rust side using the original types. Then if both are integers, we perform an add operation. If both are strings, we call Rust to concatenate them. If one is a string and another an integer, we throw an exception (call abort for now). You need to check with @ramakotareddy about how we are doing this.

[ayonam]

@ruvi-d, let me get this thing right. If I declare a variable as int | string, and I assign an int the first time, am I not allowed to assign it a string the next time? I thought that the variable can get assigned either an int or a string at any point in time. Now if my understanding is correct, then any union variable can possibly have three distinct types. One is an inherent type, which is that of an union (in this case int | string), the second is the type it has been assigned currently (could be int or string in this case), and a third type that it may have been typecast to in a certain operation (like Any or say float if the second type was int). So we need to keep track of all three at any given point of time.

My proposal was that we are keeping track of two of these in our smart pointer scheme, i.e., the first and the third one. The second one needs to be kept track of inside the union object.

[KavinduZoysa]

In ballerina streaming, we have to do the casting. So at runtime, we only need the actual type of that value. Maybe I am wrong, I am trying to figure out a usage of adding union type for boxing.

public function main() {
    int|string s = 2;
}

For the above simple example, I have implemented the rust side as follows. (please note that still, I did not consider mangling which @ramakotareddy is working)

pub struct UnionValue {
   t: String,
   value: i32
}

#[no_mangle]
pub extern "C" fn box_integer_as_union(v:i32) -> *mut UnionValue {
   let u_val = UnionValue {
      value: v,
      t:String::from("INT")
   };
   println!("{}", u_val.value);
   return Box::into_raw(Box::new(u_val));
}

Also the generated block in .ll file is,

bb0:                                              ; preds = %entry
  store i32 2, i32* %"%3", align 4
  %"%3_temp" = load i32, i32* %"%3", align 4
  %0 = call i64* @box_integer_as_union(i32 %"%3_temp")
  store i64* %0, i64** %"%1", align 8
  br label %bb2

[KavinduZoysa]

@KavinduZoysa What I mean by common storage is a single storage location of the size of the largest member of an union that is used by all members of the union. Essentially, how a union is supposed to be.

In order to support this, you need create the struct in the LLVM side itself. I suggest that you take a look at some of Ram's code on the generation of smart pointers. I faintly remember sending Ram an email detailing the steps needed to be done for this purpose. @ramakotareddy, can you please check if you can locate that email and help @KavinduZoysa with this? In case, you can't locate it, let me know and I will write out the steps again.

@ramakotareddy, could you please point me to this email?

[ramakotareddy]

Hi @KavinduZoysa , After today's call i will send steps for create struct in LLVM side.

[KavinduZoysa]

At today's meeting, we have decided only to store the value and value's inherent type. @ayonam will investigate more on an example that violates the decision.