tlang/tlang
tlang
/
tlang
mirror of https://github.com/tbklang/tlang.git
2
0
Fork 0
Code Issues 43 Projects 5 Releases Wiki Activity

Array support #81

New Issue
Closed
opened 2023-01-12 11:38:36 +00:00 by deavmi · 24 comments
deavmi commented 2023-01-12 11:38:36 +00:00
Owner
Copy Link

What is to be done?

Add support for arrays to TLang, this means both stack allocated arrays and also the syntax to use them as pointer types interchangeably. You know all that good stuff.

Roadmap

There are a few things that need to be considered.

Handling of int[] ✅

Something like int[] should automatically just be converted to int* as that makes life easier for us - it lessens the amount of work required.

Therefore we should be looking at updating the following code in symbols/typing/builtins.d's getBuiltInType():

/* Pointer handling `<type>*` */
else if(lastIndexOf(typeString, "*") > -1)
{
	long ptrTypePos = lastIndexOf(typeString, "*");
	string ptrType = typeString[0..(ptrTypePos)];
	gprintln("Pointer to '"~ptrType~"'");

	return new Pointer(tc.getType(tc.getModule(), ptrType));
}
/* Array handling `<type>[]` */
else if(lastIndexOf(typeString, "[]") > -1)
{
	long arrayTypePos = lastIndexOf(typeString, "[]");
	string arrayType = typeString[0..(arrayTypePos)];
	gprintln("Array of '"~arrayType~"'");

	return new Array(tc.getType(tc.getModule(), arrayType));
}

To return new Pointer(<...>, <...>) instead of new Array(<...>, <...>)

Status: Added as of commit 2ea4a3791290c1555d695101182426a443e91b1d on the arrays branch

Handling of int[<numeric>] 🤔

To be discussed, this will need more work. See issue #102

Handling of int[]*[]* ✅

This isn't a hard problem, the recursive nature would make it work, but the usage of lastIndexOf in the code below results in us skipping certain things:

   /**
    * FIXME: For the below we need to find which is the RIGHT-MOST and THEN
    * go from there
    *
    * This is so that we can support things such as:
    *
    * `char*[]`

    * Current problem here is that if we have `int*[]`
    * it will immediately start with `int*` -> new Pointer(int)
    *
    * Instead of `new Pointer(int*)`
    *
    * Switching the pointer-array checks arround doesn't help
    * as the above works but then `int[]*` will be new Pointer(int)
    * (and leaving out the `*`)
    */


    /* Pointer handling `<type>*` */
    else if(lastIndexOf(typeString, "*") > -1)
    {
        long ptrTypePos = lastIndexOf(typeString, "*");
        string ptrType = typeString[0..(ptrTypePos)];
        gprintln("TypeStr: "~typeString);
        gprintln("Pointer to '"~ptrType~"'", DebugType.ERROR);

        return new Pointer(tc.getType(tc.getModule(), ptrType));
    }
    /* Array handling `<type>[]` */
    else if(lastIndexOf(typeString, "[]") > -1)
    {
        long arrayTypePos = lastIndexOf(typeString, "[]");
        string arrayType = typeString[0..(arrayTypePos)];
        gprintln("Array of '"~arrayType~"'", DebugType.WARNING);

        // NOTE: We disabled the below as we are basically just a pointer type
        // return new Array(tc.getType(tc.getModule(), arrayType));
        return new Pointer(tc.getType(tc.getModule(), arrayType));
    }
## What is to be done? Add support for arrays to TLang, this means both stack allocated arrays and also the syntax to use them as pointer types interchangeably. You know all that good stuff. ## Roadmap There are a few things that need to be considered. --- ### Handling of `int[]` ✅ Something like `int[]` should automatically just be converted to `int*` as that makes life easier for us - it lessens the amount of work required. Therefore we should be looking at updating the following code in `symbols/typing/builtins.d`'s `getBuiltInType()`: ```d /* Pointer handling `<type>*` */ else if(lastIndexOf(typeString, "*") > -1) { long ptrTypePos = lastIndexOf(typeString, "*"); string ptrType = typeString[0..(ptrTypePos)]; gprintln("Pointer to '"~ptrType~"'"); return new Pointer(tc.getType(tc.getModule(), ptrType)); } /* Array handling `<type>[]` */ else if(lastIndexOf(typeString, "[]") > -1) { long arrayTypePos = lastIndexOf(typeString, "[]"); string arrayType = typeString[0..(arrayTypePos)]; gprintln("Array of '"~arrayType~"'"); return new Array(tc.getType(tc.getModule(), arrayType)); } ``` To return `new Pointer(<...>, <...>)` instead of `new Array(<...>, <...>)` **Status**: Added as of commit `2ea4a3791290c1555d695101182426a443e91b1d` on the `arrays` branch --- ### Handling of `int[<numeric>]` 🤔 To be discussed, this will need more work. See issue #102 --- ### Handling of `int[]*[]*` ✅ This isn't a hard problem, the recursive nature would make it work, but the usage of `lastIndexOf` in the code below results in us skipping certain things: ```d /** * FIXME: For the below we need to find which is the RIGHT-MOST and THEN * go from there * * This is so that we can support things such as: * * `char*[]` * Current problem here is that if we have `int*[]` * it will immediately start with `int*` -> new Pointer(int) * * Instead of `new Pointer(int*)` * * Switching the pointer-array checks arround doesn't help * as the above works but then `int[]*` will be new Pointer(int) * (and leaving out the `*`) */ /* Pointer handling `<type>*` */ else if(lastIndexOf(typeString, "*") > -1) { long ptrTypePos = lastIndexOf(typeString, "*"); string ptrType = typeString[0..(ptrTypePos)]; gprintln("TypeStr: "~typeString); gprintln("Pointer to '"~ptrType~"'", DebugType.ERROR); return new Pointer(tc.getType(tc.getModule(), ptrType)); } /* Array handling `<type>[]` */ else if(lastIndexOf(typeString, "[]") > -1) { long arrayTypePos = lastIndexOf(typeString, "[]"); string arrayType = typeString[0..(arrayTypePos)]; gprintln("Array of '"~arrayType~"'", DebugType.WARNING); // NOTE: We disabled the below as we are basically just a pointer type // return new Array(tc.getType(tc.getModule(), arrayType)); return new Pointer(tc.getType(tc.getModule(), arrayType)); } ```
deavmi added reference arrays 2023-01-12 12:42:08 +00:00
deavmi added this to the Basics milestone 2023-01-12 12:42:10 +00:00
deavmi added this to the Dependency tree, type-checking and codegen project 2023-01-12 12:42:16 +00:00
deavmi self-assigned this 2023-01-12 12:42:18 +00:00
deavmi added the
typing
dependency
parser
emit
 labels 2023-01-12 12:42:30 +00:00
deavmi added the due date 2023-01-14 2023-01-12 12:43:15 +00:00
deavmi modified the due date from 2023-01-14 to 2023-01-16 2023-02-11 11:06:32 +00:00
deavmi started working 2023-02-11 11:06:34 +00:00
deavmi commented 2023-02-11 11:47:03 +00:00
Author
Owner
Copy Link

Sub-issue 3 (int*[] and int[]*) solution ✅

Here is the solution:

    /* Pointer handling `<type>*` and Array handling `<type>*` */
    else if((lastIndexOf(typeString, "*") > -1) || (lastIndexOf(typeString, "[]") > -1))
    {
        // Find the `*` (if any)
        long starPos = lastIndexOf(typeString, "*");

        // Find the `[]` (if any)
        long brackPos = lastIndexOf(typeString, "[]");

        // Determine which one is the rightmost
        long rightmostTypePos;
        if(starPos > brackPos)
        {
            rightmostTypePos = starPos;
        }
        else
        {
            rightmostTypePos = brackPos;
        }

        long ptrTypePos = rightmostTypePos;
        string ptrType = typeString[0..(ptrTypePos)];
        gprintln("TypeStr: "~typeString);
        gprintln("Pointer to '"~ptrType~"'", DebugType.ERROR);

        return new Pointer(tc.getType(tc.getModule(), ptrType));
    }

Status: Fixed as of 32993900b592e4b4dd9680d873ee508821df83a6 on the arrays branch ✅

## Sub-issue 3 (`int*[]` and `int[]*`) solution ✅ Here is the solution: ```d /* Pointer handling `<type>*` and Array handling `<type>*` */ else if((lastIndexOf(typeString, "*") > -1) || (lastIndexOf(typeString, "[]") > -1)) { // Find the `*` (if any) long starPos = lastIndexOf(typeString, "*"); // Find the `[]` (if any) long brackPos = lastIndexOf(typeString, "[]"); // Determine which one is the rightmost long rightmostTypePos; if(starPos > brackPos) { rightmostTypePos = starPos; } else { rightmostTypePos = brackPos; } long ptrTypePos = rightmostTypePos; string ptrType = typeString[0..(ptrTypePos)]; gprintln("TypeStr: "~typeString); gprintln("Pointer to '"~ptrType~"'", DebugType.ERROR); return new Pointer(tc.getType(tc.getModule(), ptrType)); } ``` **Status**: Fixed as of `32993900b592e4b4dd9680d873ee508821df83a6` on the `arrays` branch ✅
deavmi modified the due date from 2023-01-16 to 2023-02-12 2023-02-11 12:05:47 +00:00
deavmi added a new dependency 2023-02-11 12:06:45 +00:00
#80 Pointer support
deavmi stopped working 2023-02-11 12:18:40 +00:00
1 hour 12 minutes
deavmi added a new dependency 2023-02-11 12:20:21 +00:00
#102 Stack-based array support
deavmi commented 2023-03-06 06:03:00 +00:00
Author
Owner
Copy Link

Okay this needs to be continually worked on - including today.

Okay this needs to be continually worked on - including today.
deavmi commented 2023-03-06 10:30:31 +00:00
Author
Owner
Copy Link

For non-stack arrays (effectively sugar pointer syntax) I produce a PointerDereferenceAssignmentInstruction using data popped off from the code queue.

For non-stack arrays (effectively sugar pointer syntax) I produce a `PointerDereferenceAssignmentInstruction` using data popped off from the code queue.
deavmi commented 2023-03-07 10:09:19 +00:00
Author
Owner
Copy Link

Lesser todos 🥥

These are some todo items that are of less importance and are to be finished later:

  • Constrain the index fields of any array-related things for pointer and stack-based arrays from the Value instruction type to the IntegerLiteral (or whatever it is called) instruction type
# Lesser todos 🥥 These are some todo items that are of less importance and are to be finished later: - [ ] Constrain the `index` fields of any array-related things for pointer and stack-based arrays from the `Value` instruction type to the `IntegerLiteral` (or whatever it is called) instruction type
deavmi modified the due date from 2023-02-12 to 2023-03-12 2023-03-07 10:23:39 +00:00
deavmi commented 2023-03-08 12:02:25 +00:00
Author
Owner
Copy Link

Codegen + emit ✅

On commit 98b3ab42848e940ef60a21f2755178148338ba6f we have the following apparently working:

  • Pointer-based arrays
    • Index
    • Assignment
  • Stack-based arrays
    • Index
    • Assignment
  • Stack-based array of pointer-based array
    • Index
    • Assignment
## Codegen + emit ✅ On commit `98b3ab42848e940ef60a21f2755178148338ba6f` we have the following apparently working: - [x] Pointer-based arrays - [x] Index - [x] Assignment - [x] Stack-based arrays - [x] Index - [x] Assignment - [x] Stack-based array of pointer-based array - [x] Index - [x] Assignment
deavmi commented 2023-03-08 12:03:11 +00:00
Author
Owner
Copy Link

🏖️ Not-so-lesser todos

  • Coercion of stack-based arrays to <compType>* when passed into function arguments
  • cast() support for array types 🚧
## 🏖️ Not-so-lesser todos - [x] Coercion of stack-based arrays to `<compType>*` when passed into function arguments - [x] `cast()` support for array types 🚧
deavmi commented 2023-03-08 12:06:18 +00:00
Author
Owner
Copy Link

Testing 🚧

We should setup some semantic tests, seeing as manual tests have passed, namely:

Semantic tests

  • simple_stack_arrays4.t
    • Code emit correct
    • Semantics test
  • simple_stack_array_coerce.t
    • Code emit correct
    • Semantics test
  • simple_stack_array_coerce_ptr_syntax.t
    • Code emit correct
    • Semantics test
  • complex_stack_array_coerce.t
    • Code emit correct
    • Semantics test
  • simple_pointer_array_syntax.t (blocked by #80)
    • Code emit correct
    • Semantics test

Typechecks

  • simple_stack_array_coerce_wrong.t
    • This should fail

Just emit

  • complex_stack_arrays1.t
    • Code emit correct
  • simple_arrays.t
    • Code emit correct
  • simple_arrays2.t
    • Code emit correct
  • simple_arrays4.t
    • Code emit correct
  • simple_stack_arrays2.t
    • Code emit correct
  • complex_stack_arrays1.t
    • Code emit correct
## Testing 🚧 We should setup some semantic tests, seeing as **manual tests** have passed, namely: ### Semantic tests - [x] `simple_stack_arrays4.t` - [x] Code emit correct - [x] Semantics test - [x] `simple_stack_array_coerce.t` - [x] Code emit correct - [x] Semantics test - [x] `simple_stack_array_coerce_ptr_syntax.t` - [x] Code emit correct - [x] Semantics test - [x] `complex_stack_array_coerce.t` - [x] Code emit correct - [x] Semantics test - [x] `simple_pointer_array_syntax.t` (blocked by #80) - [x] Code emit correct - [x] Semantics test ### Typechecks - [x] `simple_stack_array_coerce_wrong.t` - [x] This _should_ fail ### Just emit - [x] `complex_stack_arrays1.t` - [x] Code emit correct - [x] `simple_arrays.t` - [x] Code emit correct - [x] `simple_arrays2.t` - [x] Code emit correct - [x] `simple_arrays4.t` - [x] Code emit correct - [x] `simple_stack_arrays2.t` - [x] Code emit correct - [x] `complex_stack_arrays1.t` - [x] Code emit correct
deavmi commented 2023-03-08 13:57:33 +00:00
Author
Owner
Copy Link

Typechecking 🚧

  • We need to do typechecking on the ArrayAssignment and ArrayIndex nodes
## Typechecking 🚧 - [ ] We need to do typechecking on the `ArrayAssignment` and `ArrayIndex` nodes
deavmi commented 2023-04-11 08:04:18 +01:00
Author
Owner
Copy Link

🏖️ Not-so-lesser todos

  • Coercion of stack-based arrays to int[] when passed into function arguments

Update for stack-based arrays

I'm busy working on coercing a type like <compType>[<size>] (the argument type) to <compType>* (the parameter type) right now on the arrays branch.

> ## 🏖️ Not-so-lesser todos > > - [ ] Coercion of stack-based arrays to `int[]` when passed into function arguments ### Update for stack-based arrays I'm busy working on coercing a type like `<compType>[<size>]` (the argument type) to `<compType>*` (the parameter type) right now on the `arrays` branch.
deavmi modified the due date from 2023-03-12 to 2023-03-31 2023-04-14 09:22:09 +01:00
deavmi modified the due date from 2023-03-31 to 2023-04-30 2023-04-14 09:22:20 +01:00
deavmi modified the due date from 2023-04-30 to 2023-04-23 2023-04-14 09:22:29 +01:00
deavmi added a new dependency 2023-04-14 12:39:04 +01:00
#110 Casting improvement, parseTypedDeclaration()
deavmi commented 2023-04-17 08:04:26 +01:00
Author
Owner
Copy Link

Casting syntax ✅

As of commit 58a4374f9e97ff3372aa548d9ced6e3e674cbc53 (at most, probs earlier) we defs have casting working as the following works:

module simple_arrays2;

void function()
{
    int*[] myArray1;
    int[]* myArray2;

    myArray2 = cast(int[]*)myArray2;
    myArray2 = cast(int[][])myArray2;
    myArray2 = cast(int**)myArray2;
    myArray2 = cast(int*[])myArray2;
}

And outputs the following C code:

/**
 * TLP compiler generated code
 *
 * Module name: simple_arrays2
 * Output C file: tlangout.c
 *
 * Place any extra information by code
 * generator here
 */
#include<stdint.h>


void function();

void function()
{
	int32_t** t_aaf1735c332587181d3e8813f75a866f;
	int32_t** t_94d390c4c2ae1d6f65f21da8c8bcc710;
	t_94d390c4c2ae1d6f65f21da8c8bcc710 = (int32_t**)t_94d390c4c2ae1d6f65f21da8c8bcc710;
	t_94d390c4c2ae1d6f65f21da8c8bcc710 = (int32_t**)t_94d390c4c2ae1d6f65f21da8c8bcc710;
	t_94d390c4c2ae1d6f65f21da8c8bcc710 = (int32_t**)t_94d390c4c2ae1d6f65f21da8c8bcc710;
	t_94d390c4c2ae1d6f65f21da8c8bcc710 = (int32_t**)t_94d390c4c2ae1d6f65f21da8c8bcc710;
}


int main()
{
    return 0;
}
### Casting syntax ✅ As of commit `58a4374f9e97ff3372aa548d9ced6e3e674cbc53` (at most, probs earlier) we defs have casting working as the following works: ```d module simple_arrays2; void function() { int*[] myArray1; int[]* myArray2; myArray2 = cast(int[]*)myArray2; myArray2 = cast(int[][])myArray2; myArray2 = cast(int**)myArray2; myArray2 = cast(int*[])myArray2; } ``` And outputs the following C code: ```c /** * TLP compiler generated code * * Module name: simple_arrays2 * Output C file: tlangout.c * * Place any extra information by code * generator here */ #include<stdint.h> void function(); void function() { int32_t** t_aaf1735c332587181d3e8813f75a866f; int32_t** t_94d390c4c2ae1d6f65f21da8c8bcc710; t_94d390c4c2ae1d6f65f21da8c8bcc710 = (int32_t**)t_94d390c4c2ae1d6f65f21da8c8bcc710; t_94d390c4c2ae1d6f65f21da8c8bcc710 = (int32_t**)t_94d390c4c2ae1d6f65f21da8c8bcc710; t_94d390c4c2ae1d6f65f21da8c8bcc710 = (int32_t**)t_94d390c4c2ae1d6f65f21da8c8bcc710; t_94d390c4c2ae1d6f65f21da8c8bcc710 = (int32_t**)t_94d390c4c2ae1d6f65f21da8c8bcc710; } int main() { return 0; } ```
deavmi commented 2023-04-17 08:49:58 +01:00
Author
Owner
Copy Link

I think coercion is broken in how we check for it in canCoerceStackArray as the code below successfully coerces when it shouldn't:

module complex_stack_array_coerce;

void coerce(int** in)
{
    in[0] = 69;
    in[1] = 420;
}

int function()
{
    int[2] stackArr;
    discard coerce(stackArr);

    return stackArr[0]+stackArr[1];
}

The output we are getting is:

Len: 4]
[INFO] getBuiltInType(int**)
[INFO] TypeStr: int**
[ERROR] Pointer to 'int*'
[INFO] getBuiltInType(int*)
[INFO] TypeStr: int*
[ERROR] Pointer to 'int'
[INFO] getBuiltInType(int)
[ERROR] isSameType(55,int**): false
[ERROR] isSameType(int**,int*): true
[INFO] Stack-based array has been coerced for function call

This could possibly be in isSameType as int** and int* are not the same, so it seems it coerced correctly but the return isSameType(Type, Type) is wrong. See #80 for this fix.

I think coercion is broken in how we check for it in `canCoerceStackArray` as the code below successfully coerces when it shouldn't: ```d module complex_stack_array_coerce; void coerce(int** in) { in[0] = 69; in[1] = 420; } int function() { int[2] stackArr; discard coerce(stackArr); return stackArr[0]+stackArr[1]; } ``` The output we are getting is: ``` Len: 4] [INFO] getBuiltInType(int**) [INFO] TypeStr: int** [ERROR] Pointer to 'int*' [INFO] getBuiltInType(int*) [INFO] TypeStr: int* [ERROR] Pointer to 'int' [INFO] getBuiltInType(int) [ERROR] isSameType(55,int**): false [ERROR] isSameType(int**,int*): true [INFO] Stack-based array has been coerced for function call ``` This **could** possibly be in `isSameType` as `int**` and `int*` are not the same, so it seems it coerced correctly but the `return isSameType(Type, Type)` is wrong. See #80 for this fix.
deavmi commented 2023-04-17 16:00:38 +01:00
Author
Owner
Copy Link

Testing 🚧

We should setup some semantic tests, seeing as manual tests have passed, namely:

Semantic tests

  • simple_stack_arrays4.t
    • Code emit correct
    • Semantics test
  • simple_stack_array_coerce.t
    • Code emit correct
    • Semantics test
  • simple_stack_array_coerce_ptr_syntax.t (blocked by #80)
    • Code emit correct
    • Semantics test

Typechecks

  • simple_stack_array_coerce_wrong.t
    • This should fail

Just emit

  • complex_stack_arrays1.t
    • Code emit correct
  • simple_arrays.t
    • Code emit correct
  • simple_arrays2.t
    • Code emit correct
  • simple_arrays4.t
    • Code emit correct
  • simple_stack_arrays2.t
    • Code emit correct
  • complex_stack_arrays1.t
    • Code emit correct

Currently simple_stack_array_coerce_wrong.t doesn't fail but with new code from pointers it should

> ## Testing 🚧 > > We should setup some semantic tests, seeing as **manual tests** have passed, namely: > > ### Semantic tests > > - [x] `simple_stack_arrays4.t` > - [x] Code emit correct > - [x] Semantics test > - [x] `simple_stack_array_coerce.t` > - [x] Code emit correct > - [x] Semantics test > - [ ] `simple_stack_array_coerce_ptr_syntax.t` (blocked by #80) > - [ ] Code emit correct > - [ ] Semantics test > > ### Typechecks > > - [ ] `simple_stack_array_coerce_wrong.t` > - [ ] This _should_ fail > > ### Just emit > > - [x] `complex_stack_arrays1.t` > - [x] Code emit correct > - [x] `simple_arrays.t` > - [x] Code emit correct > - [x] `simple_arrays2.t` > - [x] Code emit correct > - [x] `simple_arrays4.t` > - [x] Code emit correct > - [x] `simple_stack_arrays2.t` > - [x] Code emit correct > - [x] `complex_stack_arrays1.t` > - [x] Code emit correct > Currently `simple_stack_array_coerce_wrong.t` doesn't fail but with new code from `pointers` it should
deavmi commented 2023-04-17 16:01:13 +01:00
Author
Owner
Copy Link

Other todos

  • Add a more complex coercion via function call for stack arrays
## Other todos - [x] Add a more complex coercion via function call for stack arrays
deavmi started working 2023-04-17 16:01:25 +01:00
deavmi commented 2023-04-17 16:13:02 +01:00
Author
Owner
Copy Link

Merge seems fine, preliminary CI too

  • need to double check
  • add more tests to CI and then push
  • finish any above todos
Merge seems fine, preliminary CI too - [x] need to double check - [x] add more tests to CI and then push - [x] finish any above todos
deavmi commented 2023-04-17 16:26:59 +01:00
Author
Owner
Copy Link

Pointer "array-syntax"

  • check simple_pointer_array_syntax.t
### Pointer _"array-syntax"_ - [x] check `simple_pointer_array_syntax.t`
deavmi commented 2023-04-20 08:30:22 +01:00
Author
Owner
Copy Link

Pointer "array-syntax"

  • check simple_pointer_array_syntax.t

Works ✅

> ### Pointer _"array-syntax"_ > > - [x] check `simple_pointer_array_syntax.t` Works ✅
deavmi commented 2023-04-20 08:37:45 +01:00
Author
Owner
Copy Link

Testing 🚧

We should setup some semantic tests, seeing as manual tests have passed, namely:

Semantic tests

  • simple_stack_arrays4.t
    • Code emit correct
    • Semantics test
  • simple_stack_array_coerce.t
    • Code emit correct
    • Semantics test
  • simple_stack_array_coerce_ptr_syntax.t
    • Code emit correct
    • Semantics test
  • simple_pointer_array_syntax.t (blocked by #80)
    • Code emit correct
    • Semantics test

Typechecks

  • simple_stack_array_coerce_wrong.t
    • This should fail

Just emit

  • complex_stack_arrays1.t
    • Code emit correct
  • simple_arrays.t
    • Code emit correct
  • simple_arrays2.t
    • Code emit correct
  • simple_arrays4.t
    • Code emit correct
  • simple_stack_arrays2.t
    • Code emit correct
  • complex_stack_arrays1.t
    • Code emit correct

simple_stack_array_coerce_ptr_syntax.t works ✅

> ## Testing 🚧 > > We should setup some semantic tests, seeing as **manual tests** have passed, namely: > > ### Semantic tests > > - [x] `simple_stack_arrays4.t` > - [x] Code emit correct > - [x] Semantics test > - [x] `simple_stack_array_coerce.t` > - [x] Code emit correct > - [x] Semantics test > - [ ] `simple_stack_array_coerce_ptr_syntax.t` > - [ ] Code emit correct > - [ ] Semantics test > - [x] `simple_pointer_array_syntax.t` (blocked by #80) > - [x] Code emit correct > - [x] Semantics test > > ### Typechecks > > - [ ] `simple_stack_array_coerce_wrong.t` > - [ ] This _should_ fail > > ### Just emit > > - [x] `complex_stack_arrays1.t` > - [x] Code emit correct > - [x] `simple_arrays.t` > - [x] Code emit correct > - [x] `simple_arrays2.t` > - [x] Code emit correct > - [x] `simple_arrays4.t` > - [x] Code emit correct > - [x] `simple_stack_arrays2.t` > - [x] Code emit correct > - [x] `complex_stack_arrays1.t` > - [x] Code emit correct > `simple_stack_array_coerce_ptr_syntax.t` works ✅
deavmi commented 2023-04-20 08:50:45 +01:00
Author
Owner
Copy Link

Testing 🚧

We should setup some semantic tests, seeing as manual tests have passed, namely:

Semantic tests

  • simple_stack_arrays4.t
    • Code emit correct
    • Semantics test
  • simple_stack_array_coerce.t
    • Code emit correct
    • Semantics test
  • simple_stack_array_coerce_ptr_syntax.t
    • Code emit correct
    • Semantics test
  • simple_pointer_array_syntax.t (blocked by #80)
    • Code emit correct
    • Semantics test

Typechecks

  • simple_stack_array_coerce_wrong.t
    • This should fail

Just emit

  • complex_stack_arrays1.t
    • Code emit correct
  • simple_arrays.t
    • Code emit correct
  • simple_arrays2.t
    • Code emit correct
  • simple_arrays4.t
    • Code emit correct
  • simple_stack_arrays2.t
    • Code emit correct
  • complex_stack_arrays1.t
    • Code emit correct

simple_stack_array_coerce_wrong.t works (it fails with a type mismatch error as it should) ✅

> ## Testing 🚧 > > We should setup some semantic tests, seeing as **manual tests** have passed, namely: > > ### Semantic tests > > - [x] `simple_stack_arrays4.t` > - [x] Code emit correct > - [x] Semantics test > - [x] `simple_stack_array_coerce.t` > - [x] Code emit correct > - [x] Semantics test > - [x] `simple_stack_array_coerce_ptr_syntax.t` > - [x] Code emit correct > - [x] Semantics test > - [x] `simple_pointer_array_syntax.t` (blocked by #80) > - [x] Code emit correct > - [x] Semantics test > > ### Typechecks > > - [ ] `simple_stack_array_coerce_wrong.t` > - [ ] This _should_ fail > > ### Just emit > > - [x] `complex_stack_arrays1.t` > - [x] Code emit correct > - [x] `simple_arrays.t` > - [x] Code emit correct > - [x] `simple_arrays2.t` > - [x] Code emit correct > - [x] `simple_arrays4.t` > - [x] Code emit correct > - [x] `simple_stack_arrays2.t` > - [x] Code emit correct > - [x] `complex_stack_arrays1.t` > - [x] Code emit correct > `simple_stack_array_coerce_wrong.t` works (it fails with a type mismatch error as it should) ✅
deavmi commented 2023-04-20 08:51:21 +01:00
Author
Owner
Copy Link

Everything is almost done, just maybe some other tests here and there but honestly this looks good.

Everything is almost done, just maybe some other tests here and there but honestly this looks good.
deavmi commented 2023-04-20 09:39:57 +01:00
Author
Owner
Copy Link

Other todos

  • Add a more complex coercion via function call for stack arrays

I have done this with complex_stack_array_coerce.t ✅

> ## Other todos > > - [ ] Add a more complex coercion via function call for stack arrays I have done this with `complex_stack_array_coerce.t` ✅
deavmi commented 2023-04-20 10:17:55 +01:00
Author
Owner
Copy Link

Other todos

  • Add a more complex coercion via function call for stack arrays

This is done as of commit e4c0f08b3654d50cb2af3aed6de92ceb75eb60e0, I added many:

Test cases

  • Added extensive positive test case complex_stack_array_coerce_permutation_good.t which has a lot of different ways to write int** (think int*[] etc)
  • Added negative test cases complex_stack_array_coerce_bad1.t, complex_stack_array_coerce_bad2.t and complex_stack_array_coerce_bad3.t

CI passes ✅

> ## Other todos > > - [ ] Add a more complex coercion via function call for stack arrays This is done as of commit `e4c0f08b3654d50cb2af3aed6de92ceb75eb60e0`, I added many: Test cases - Added extensive positive test case `complex_stack_array_coerce_permutation_good.t` which has a lot of different ways to write `int**` (think `int*[]` etc) - Added negative test cases `complex_stack_array_coerce_bad1.t`, `complex_stack_array_coerce_bad2.t` and `complex_stack_array_coerce_bad3.t` CI passes ✅
deavmi commented 2023-04-20 10:19:09 +01:00
Author
Owner
Copy Link

Merge seems fine, preliminary CI too

  • need to double check
  • add more tests to CI and then push
  • finish any above todos

I'm gonna merge now rather than later, pretty sure most TODOs are done anyways - if not we can always open a branch for type checking again but it seems the typechecking is suprisingly solid - most likely resulting from that new code in pointers which updated isSameType(Type t1, Type t2) to check pointers correctly.

> Merge seems fine, preliminary CI too > > - [x] need to double check > - [x] add more tests to CI and then push > - [x] finish any above todos I'm gonna merge now rather than later, pretty sure most TODOs are done anyways - if not we can always open a branch for type checking again but it seems the typechecking is suprisingly solid - most likely resulting from that new code in `pointers` which updated `isSameType(Type t1, Type t2)` to check pointers correctly.
deavmi commented 2023-04-20 10:21:23 +01:00
Author
Owner
Copy Link

All looks good, going to do a squash merge in a minute.

All looks good, going to do a squash merge in a minute.
deavmi commented 2023-04-20 10:24:28 +01:00
Author
Owner
Copy Link

Closing

Closing
deavmi stopped working 2023-04-20 10:24:28 +01:00
2 days 18 hours
Sign in to join this conversation.
arrays
Branches Tags
Clear current reference
master
vardec_varass_dependency
feature/comments
feature/reporting
bugfix/single_line_comment_bug
feature/logging_upgrade
feature/multi_module
feature/unused_vars_detection
feature/container_methods
feature/strat_resolve_collectors
feature/predicate_based_resolver
feature/modifiers
feature/operator_precedence
feature/poolmngr
hotfix/func_defs_in_dep_generator
feature/lexer_improvements
feature/structs
feature/behavec_preinline
bugfix/fix_multi_compile
feature/annotations
hotfix/simply_varexp_dnode_generation
hotfix/jcli_upgrade_fix
feature/class_static_init
feature/universal_coercion
feature/cloneability
hotfix/expect_exception_change
bugfix/recursive_return_statement_check
bugfix/require_return
bugfix/return_type
feature/cleanup1
feature/clean_lexer_interface
research/gmalloc
feature/type_enforcer_cast_instr_emit
feature/meta_programming
feature/direct_func_call
bugfix/return_position
bugfix/is_same_type_fallback
feature/lexer_interface
feature/parser_interface
arrays
pointers
bugfix/function_parameter_type_parse
casting
compiler_object
extern_symbols
literal_encodings
uniform_stdalone_varass
remove_typequeue
linearizer_cleanup
parsetypedev_fix
modules
loops
conditionals
vdva_func_param_merge
function_parameters_fix
path_dependency
function_dep
compiler_levels
parser
constants
constants_float
develop
typecheck
deps_refactor
codegen
lexer
typecheck_refactor_varexp_makeacyclic
weighting
testing_thing
typecheck_refactor_varexp
typecheck_refactor
type_check_codegen_reducedparseclass_excep
typecheck_codegen
typecheck_codegen_educedparseclass
typecheck_reliancetree
static_support
codegen.sync-conflict-20210606-150925-O3W7KWN
develop.sync-conflict-20210606-150924-O3W7KWN
struct_support
typecheck.sync-conflict-20210606-150925-O3W7KWN
entity_declaration_type_checking
symbol_table
parser.sync-conflict-20210405-185821-O3W7KWN
parser_exception_before
develop_before_lexer_parser_merge_parseName
if_statement_parsing
exception_except
expression_parsing
master.sync-conflict-20210316-165421-O3W7KWN
expression_parsing.sync-conflict-20210316-090018-O3W7KWN
Clear current reference
multimodule/changeset2
multimodule/changeset1
pointer_cast_merge
parsetypeddeclaration_onlytype_parsecast_new
pointers_coerce
v0.5.3
v0.5.2
v0.5.1
v0.5.0
v0.4.4
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.1.0
v0.0.5
v0.0.4
v0.0.3
v0.0.2
v0.0.1
Labels
Clear labels   
dependency

Dependency tree generation

  
emit

Code emitting

  
hashmapper

Anything pertaining to the HashMapper symbol mapping code

  
lebanonmapper

Anything pertaining to the LebanonMapper symbol mapping code

  
lexer

Related to the tokenizer

  
meta

Meta processor related

  
needsfix

Urgent fix required

  
parser

Parser related

  
qol

Quality-of-life related

  
question

A question, not needed fix

  
resolution

Related to the resolver

  
typing

TypeChecker and Resolver related

No Label
dependency
emit
hashmapper
lebanonmapper
lexer
meta
needsfix
parser
qol
question
resolution
typing
Milestone
Clear milestone
No items
No Milestone
Basics
Projects
Clear projects
No project
Dependency tree, type-checking and codegen
Assignees
Clear assignees
No Assignees
deavmi
1 Participants
Notifications
Total Time Spent: 2 days 19 hours
deavmi
2 days 19 hours
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

2023-04-23

Depends on
#110 Casting improvement, parseTypedDeclaration()
tlang/tlang
You do not have permission to read 2 dependencies
Reference: tlang/tlang#81
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?