🧠️ Feature: Universal coercion and type enforcer #115

New Issue

deavmi · 2023-04-21T14:22:01+01:00

deavmi commented

2023-04-21 14:22:01 +01:00

What is it?

A few things:

To have pre-defined coercion rules (only on literals - LiteralValue instructions, anything else requires a cast if size is big->small)
To have a "type enforcer" method which checks the following:
- Is the two types equal (via isSameType(Type t1, Type t2))
- If types are not equal and coercion is allowed then attempt to do so
A single call to typeEnforce(Type t1, Value v2, bool coerce = false) that can be used anywhere in the typechecker to do these checks (and cast towards the coerced type by generating a CastedValueInstruction)

Things to change:

Make sure that attemptCoercion(Type, Value) only throws CoercionException

Things to add:

A new kind-of TypeCheckerException, CoercionException, which is thrown when attemptCOercion(Type, Value) fails

## What is it? A few things: - [ ] To have pre-defined coercion rules (only on literals - `LiteralValue` instructions, anything else requires a `cast` if size is big->small) - [x] To have a _"type enforcer"_ method which checks the following: - [x] Is the two types equal (via `isSameType(Type t1, Type t2)`) - [x] If types are **not** equal and coercion **is allowed** then attempt to do so - [x] A single call to `typeEnforce(Type t1, Value v2, bool coerce = false)` that can be used anywhere in the typechecker to do these checks (**and** cast towards the coerced type by generating a `CastedValueInstruction`) Things to **change**: - [x] Make sure that `attemptCoercion(Type, Value)` _only_ throws `CoercionException` Things to **add**: - [x] A new kind-of `TypeCheckerException`, `CoercionException`, which is thrown when `attemptCOercion(Type, Value)` fails

deavmi self-assigned this 2023-04-21 14:31:09 +01:00

deavmi added this to the Dependency tree, type-checking and codegen project 2023-04-21 14:31:13 +01:00

deavmi added this to the Basics milestone 2023-04-21 14:31:18 +01:00

deavmi added a new dependency 2023-04-21 14:37:01 +01:00

#113 🐞️ Functions: Expressionless return and enforcing requirement

deavmi added the

typing

label 2023-04-21 14:46:43 +01:00

deavmi added reference feature/universal_coercion

2023-04-21 14:46:53 +01:00

deavmi added the due date 2023-04-30

2023-04-21 14:47:04 +01:00

deavmi changed title from ~~Universal coercion~~ to 🧠️ Feature: Universal coercion

2023-04-21 14:47:28 +01:00

deavmi commented

2023-04-22 14:53:12 +01:00

Should take in arguments rather Type t1, Value v2.

Should take in arguments rather `Type t1, Value v2`.

deavmi commented

2023-04-22 14:59:53 +01:00

Should take in arguments rather Type t1, Value v2.

Updated to this now

>Should take in arguments rather `Type t1, Value v2`. Updated to this now

deavmi started working 2023-04-23 13:00:23 +01:00

deavmi commented

2023-04-23 13:20:49 +01:00

Work on this is going well, I am writing a unit test right now to test how I would use it on practice, I am then going to update the attemptCoercion method to effectively support all sorts of instructions (basically any Value instruction) and then use coercion rules to try and coerce.

Work on this is going well, I am writing a unit test right now to test how I would use it on practice, I am then going to update the `attemptCoercion` method to effectively support all sorts of instructions (basically any Value instruction) and then use coercion rules to try and coerce.

deavmi stopped working 2023-04-23 13:24:30 +01:00

24 minutes 7 seconds

deavmi started working 2023-04-23 13:44:59 +01:00

deavmi commented

2023-04-23 15:22:10 +01:00

Mmh, do we want to auto coerce a lot of these things?

Look, it makes sense for the LiteralValue instructions as we then leave it really up to the C emitter at the end to do the right thing, however, and I am spit-balling here. If we were to coerce the value as shown below (in the return statement):

ubyte value = 2;

uint function()
{
	return value;
}

Then we would automatically be updating the type of the value instruction as part of the ReturnInstruction, it doesn't necessarily make sense to do that automatically - at all because it can result in the wrong code if we were to be emitting for something like JVM which really cares, instead of the DGen emitter which relies on C in that sense.

Therefore I think we should not add any of that sort of funcitonality to attemptCoerce(Type, Value), rather we should leave it to require a cast as normal as atleast then we could control conversion in the CodeEmitter irrespective of what emitter was used DGen (C emitter) or any future JVM emitter for example.

However, what we should do is, in the case of literals and so on, is use typeEnforce(Type, Value, true) where we can - such as in return statements - but only for LiteralValue. I think it is good to require a cast, remember if we were to do proper auto coercion for any instruction it would actually require an instruction replace (with embed) - we don't want to do that - that was never the goal.

Mmh, do we want to auto coerce a lot of these things? Look, it makes sense for the `LiteralValue` instructions as we then leave it really up to the C emitter at the end to do the right thing, however, and I am spit-balling here. If we were to coerce the value as shown below (in the return statement): ```d ubyte value = 2; uint function() { return value; } ``` Then we would automatically be updating the type of the `value` instruction as part of the `ReturnInstruction`, it doesn't necessarily make sense to do that automatically - at all because it can result in the wrong code _if_ we were to be emitting for something like JVM which really cares, instead of the `DGen` emitter which relies on C in that sense. --- Therefore I think we should not add any of that sort of funcitonality to `attemptCoerce(Type, Value)`, _rather_ we should leave it to require a cast as normal as atleast then we could control conversion in the `CodeEmitter` irrespective of what emitter was used `DGen` (C emitter) or any future JVM emitter for example. **However**, what we should do is, in the case of literals and so on, is use `typeEnforce(Type, Value, true)` where we can - such as in return statements - but **only** for `LiteralValue`. I think it is good to require a cast, remember if we were to do proper auto coercion for _any_ instruction it would actually require an instruction replace (with embed) - we don't want to do that - that was never the goal.

deavmi commented

2023-04-23 15:48:15 +01:00

Mmh, do we want to auto coerce a lot of these things?

Look, it makes sense for the LiteralValue instructions as we then leave it really up to the C emitter at the end to do the right thing, however, and I am spit-balling here. If we were to coerce the value as shown below (in the return statement):
ubyte value = 2;

uint function()
{
	return value;
}
Then we would automatically be updating the type of the value instruction as part of the ReturnInstruction, it doesn't necessarily make sense to do that automatically - at all because it can result in the wrong code if we were to be emitting for something like JVM which really cares, instead of the DGen emitter which relies on C in that sense.

Therefore I think we should not add any of that sort of funcitonality to attemptCoerce(Type, Value), rather we should leave it to require a cast as normal as atleast then we could control conversion in the CodeEmitter irrespective of what emitter was used DGen (C emitter) or any future JVM emitter for example.

However, what we should do is, in the case of literals and so on, is use typeEnforce(Type, Value, true) where we can - such as in return statements - but only for LiteralValue. I think it is good to require a cast, remember if we were to do proper auto coercion for any instruction it would actually require an instruction replace (with embed) - we don't want to do that - that was never the goal.

I have re-defined the TODOs for this issue to reflect this now 👍

> Mmh, do we want to auto coerce a lot of these things? > > Look, it makes sense for the `LiteralValue` instructions as we then leave it really up to the C emitter at the end to do the right thing, however, and I am spit-balling here. If we were to coerce the value as shown below (in the return statement): > > ```d > ubyte value = 2; > > uint function() > { > return value; > } > ``` > > Then we would automatically be updating the type of the `value` instruction as part of the `ReturnInstruction`, it doesn't necessarily make sense to do that automatically - at all because it can result in the wrong code _if_ we were to be emitting for something like JVM which really cares, instead of the `DGen` emitter which relies on C in that sense. > > --- > > Therefore I think we should not add any of that sort of funcitonality to `attemptCoerce(Type, Value)`, _rather_ we should leave it to require a cast as normal as atleast then we could control conversion in the `CodeEmitter` irrespective of what emitter was used `DGen` (C emitter) or any future JVM emitter for example. > > **However**, what we should do is, in the case of literals and so on, is use `typeEnforce(Type, Value, true)` where we can - such as in return statements - but **only** for `LiteralValue`. I think it is good to require a cast, remember if we were to do proper auto coercion for _any_ instruction it would actually require an instruction replace (with embed) - we don't want to do that - that was never the goal. I have re-defined the TODOs for this issue to reflect this now :+1:

deavmi commented

2023-04-23 16:01:10 +01:00

As of commit 332413279b26a840e1fc5a93af5ba77f4ace68eb we have what seems to be a working typeEnforce(Type, Value, bool coerce = false) method ✅

As of commit `332413279b26a840e1fc5a93af5ba77f4ace68eb` we have what _seems_ to be a working `typeEnforce(Type, Value, bool coerce = false)` method ✅

deavmi stopped working 2023-04-23 16:01:31 +01:00

2 hours 16 minutes

deavmi changed title from ~~🧠️ Feature: Universal coercion~~ to 🧠️ Feature: Universal coercion and type enforcer

2023-04-23 16:59:26 +01:00

deavmi commented

2023-04-23 17:01:29 +01:00

What is it?

A few things:

To have pre-defined coercion rules (only on literals - LiteralValue instructions, anything else requires a cast)

To have a "type enforcer" method which checks the following:

Is the two types equal (via isSameType(Type t1, Type t2))

If types are not equal and coercion is allowed then attempt to do so

A single call to typeEnforce(Type t1, Value v2, bool coerce = false) that can be used anywhere in the typechecker to do these checks

Things to change:

Make sure that attemptCoercion(Type, Value) only throws CoercionException

Things to add:

A new kind-of TypeCheckerException, CoercionException, which is thrown when attemptCOercion(Type, Value) fails

For the first item on the list I want to finish documenting it all and making the exception messages a little nicer, then I can check it off.
The last thing to do will be making use of typeEnforcer() everywhere

> ## What is it? > > A few things: > > - [ ] To have pre-defined coercion rules (only on literals - `LiteralValue` instructions, anything else requires a `cast`) > - [x] To have a _"type enforcer"_ method which checks the following: > - [x] Is the two types equal (via `isSameType(Type t1, Type t2)`) > - [x] If types are **not** equal and coercion **is allowed** then attempt to do so > - [ ] A single call to `typeEnforce(Type t1, Value v2, bool coerce = false)` that can be used anywhere in the typechecker to do these checks > > Things to **change**: > > - [x] Make sure that `attemptCoercion(Type, Value)` _only_ throws `CoercionException` > > Things to **add**: > > - [x] A new kind-of `TypeCheckerException`, `CoercionException`, which is thrown when `attemptCOercion(Type, Value)` fails - [ ] For the first item on the list I want to finish documenting it all and making the exception messages a little nicer, then I can check it off. - [ ] The last thing to do will be making use of `typeEnforcer()` everywhere

deavmi commented

2023-05-29 15:36:35 +01:00

Bump, this needs to be looked into and well worked on more. I am sure, from when I last looked at it, that the type enforcer function was ready to be used (as in already implemented) just needed to actually use it and then test it.

Bump, this needs to be looked into and well worked on more. I am sure, from when I last looked at it, that the type enforcer function was ready to be used (as in already implemented) just needed to _actually_ use it and then test it.

deavmi started working 2023-05-29 15:36:40 +01:00

deavmi modified the due date from 2023-04-30 to 2023-06-11

2023-05-29 15:36:49 +01:00

deavmi stopped working 2023-05-29 15:36:51 +01:00

11 seconds

deavmi referenced this issue

2023-05-29 15:55:19 +01:00

🧠 Feature: Meta-programming engine #116

deavmi referenced this issue

2023-05-29 16:01:36 +01:00

🧠 Feature: Meta-programming engine #116

deavmi started working 2023-05-29 16:34:32 +01:00

deavmi commented

2023-05-29 16:35:03 +01:00

Updated to latest base of vardec)varass_dependency ✅

Updated to latest base of `vardec)varass_dependency` ✅

deavmi stopped working 2023-05-29 16:35:07 +01:00

35 seconds

deavmi removed the due date 2023-06-11

2023-07-07 10:15:10 +01:00

deavmi started working 2023-07-07 10:15:12 +01:00

deavmi added the due date 2023-07-16

2023-07-07 10:15:20 +01:00

deavmi commented

2023-07-07 10:15:26 +01:00

Working on this again now.

deavmi commented

2023-07-07 10:45:51 +01:00

Added size-based test when both the to-type and provided-type are numerical types.

Complete with unit tests for positive and negative cases.

So far only Variable declaration is calling this.

Added size-based test when both the to-type and provided-type are numerical types. Complete with unit tests for positive and negative cases. So far only Variable declaration is calling this.

deavmi commented

2023-07-07 10:48:20 +01:00

Unit tests (not test cases) seem to be failing:

[INFO] VibeCheck?
[INFO] typeEnforce(t1=uint, v2=[Instruction: tlang.compiler.codegen.instruction.FetchValueVar:fetchVarValName: myVar, VarLen: 1], attemptCoerce=true): Leaving
core.exception.AssertError@source/tlang/compiler/typecheck/core.d(489): unittest failure
----------------
??:? _d_unittestp [0x6700f1]
source/tlang/compiler/typecheck/core.d:489 void tlang.compiler.typecheck.core.TypeChecker.__unittest_L438_C5() [0x64d9c7]
??:? void tlang.compiler.typecheck.core.__modtest() [0x6549fe]
??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*) [0x690ae6]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) [0x66653f]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x67d08f]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x67d5d5]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x67d01d]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x666511]
??:? runModuleUnitTests [0x69091e]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x678014]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x677fa1]
??:? _d_run_main2 [0x677f0a]
??:? _d_run_main [0x677cf3]
/usr/include/dmd/druntime/import/core/internal/entrypoint.d:29 main [0x593151]
??:? [0x7fcdca7e6b49]
??:? __libc_start_main [0x7fcdca7e6c0a]
??:? _start [0x5929a4]
1/5 modules FAILED unittests
Error Program exited with code 1

Could be a case of a tets case that should now pass based on coercion.

Unit tests (not test cases) seem to be failing: ``` [INFO] VibeCheck? [INFO] typeEnforce(t1=uint, v2=[Instruction: tlang.compiler.codegen.instruction.FetchValueVar:fetchVarValName: myVar, VarLen: 1], attemptCoerce=true): Leaving core.exception.AssertError@source/tlang/compiler/typecheck/core.d(489): unittest failure ---------------- ??:? _d_unittestp [0x6700f1] source/tlang/compiler/typecheck/core.d:489 void tlang.compiler.typecheck.core.TypeChecker.__unittest_L438_C5() [0x64d9c7] ??:? void tlang.compiler.typecheck.core.__modtest() [0x6549fe] ??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*) [0x690ae6] ??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) [0x66653f] ??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x67d08f] ??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x67d5d5] ??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x67d01d] ??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x666511] ??:? runModuleUnitTests [0x69091e] ??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x678014] ??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x677fa1] ??:? _d_run_main2 [0x677f0a] ??:? _d_run_main [0x677cf3] /usr/include/dmd/druntime/import/core/internal/entrypoint.d:29 main [0x593151] ??:? [0x7fcdca7e6b49] ??:? __libc_start_main [0x7fcdca7e6c0a] ??:? _start [0x5929a4] 1/5 modules FAILED unittests Error Program exited with code 1 ``` Could be a case of a tets case that should now pass based on coercion.

deavmi commented

2023-07-07 10:51:21 +01:00

Unit tests (not test cases) seem to be failing:

[INFO] VibeCheck?
[INFO] typeEnforce(t1=uint, v2=[Instruction: tlang.compiler.codegen.instruction.FetchValueVar:fetchVarValName: myVar, VarLen: 1], attemptCoerce=true): Leaving
core.exception.AssertError@source/tlang/compiler/typecheck/core.d(489): unittest failure
----------------
??:? _d_unittestp [0x6700f1]
source/tlang/compiler/typecheck/core.d:489 void tlang.compiler.typecheck.core.TypeChecker.__unittest_L438_C5() [0x64d9c7]
??:? void tlang.compiler.typecheck.core.__modtest() [0x6549fe]
??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*) [0x690ae6]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) [0x66653f]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x67d08f]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x67d5d5]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x67d01d]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x666511]
??:? runModuleUnitTests [0x69091e]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x678014]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x677fa1]
??:? _d_run_main2 [0x677f0a]
??:? _d_run_main [0x677cf3]
/usr/include/dmd/druntime/import/core/internal/entrypoint.d:29 main [0x593151]
??:? [0x7fcdca7e6b49]
??:? __libc_start_main [0x7fcdca7e6c0a]
??:? _start [0x5929a4]
1/5 modules FAILED unittests
Error Program exited with code 1

Could be a case of a tets case that should now pass based on coercion.

Well from the test case:

// 2) The enforcement will fail as coercion of non-literals is NOT allowed
try
{
	tc.typeEnforce(funcReturnType, varFetch, true);
	assert(false);
}
catch(CoercionException e)
{
	assert(true);
}

THis is no longer true, it IS allowed - I am legit trying to implement that. Lmao

> Unit tests (not test cases) seem to be failing: > > ``` > [INFO] VibeCheck? > [INFO] typeEnforce(t1=uint, v2=[Instruction: tlang.compiler.codegen.instruction.FetchValueVar:fetchVarValName: myVar, VarLen: 1], attemptCoerce=true): Leaving > core.exception.AssertError@source/tlang/compiler/typecheck/core.d(489): unittest failure > ---------------- > ??:? _d_unittestp [0x6700f1] > source/tlang/compiler/typecheck/core.d:489 void tlang.compiler.typecheck.core.TypeChecker.__unittest_L438_C5() [0x64d9c7] > ??:? void tlang.compiler.typecheck.core.__modtest() [0x6549fe] > ??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*) [0x690ae6] > ??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) [0x66653f] > ??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x67d08f] > ??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x67d5d5] > ??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x67d01d] > ??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x666511] > ??:? runModuleUnitTests [0x69091e] > ??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x678014] > ??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x677fa1] > ??:? _d_run_main2 [0x677f0a] > ??:? _d_run_main [0x677cf3] > /usr/include/dmd/druntime/import/core/internal/entrypoint.d:29 main [0x593151] > ??:? [0x7fcdca7e6b49] > ??:? __libc_start_main [0x7fcdca7e6c0a] > ??:? _start [0x5929a4] > 1/5 modules FAILED unittests > Error Program exited with code 1 > ``` > > Could be a case of a tets case that should now pass based on coercion. Well from the test case: ``` // 2) The enforcement will fail as coercion of non-literals is NOT allowed try { tc.typeEnforce(funcReturnType, varFetch, true); assert(false); } catch(CoercionException e) { assert(true); } ``` THis is no longer true, it IS allowed - I am legit trying to implement that. Lmao

deavmi commented

2023-07-07 10:54:34 +01:00

Unit tests (not test cases) seem to be failing:

[INFO] VibeCheck?
[INFO] typeEnforce(t1=uint, v2=[Instruction: tlang.compiler.codegen.instruction.FetchValueVar:fetchVarValName: myVar, VarLen: 1], attemptCoerce=true): Leaving
core.exception.AssertError@source/tlang/compiler/typecheck/core.d(489): unittest failure
----------------
??:? _d_unittestp [0x6700f1]
source/tlang/compiler/typecheck/core.d:489 void tlang.compiler.typecheck.core.TypeChecker.__unittest_L438_C5() [0x64d9c7]
??:? void tlang.compiler.typecheck.core.__modtest() [0x6549fe]
??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*) [0x690ae6]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) [0x66653f]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x67d08f]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x67d5d5]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x67d01d]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x666511]
??:? runModuleUnitTests [0x69091e]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x678014]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x677fa1]
??:? _d_run_main2 [0x677f0a]
??:? _d_run_main [0x677cf3]
/usr/include/dmd/druntime/import/core/internal/entrypoint.d:29 main [0x593151]
??:? [0x7fcdca7e6b49]
??:? __libc_start_main [0x7fcdca7e6c0a]
??:? _start [0x5929a4]
1/5 modules FAILED unittests
Error Program exited with code 1

Could be a case of a tets case that should now pass based on coercion.

Fixed now ✅

> Unit tests (not test cases) seem to be failing: > > ``` > [INFO] VibeCheck? > [INFO] typeEnforce(t1=uint, v2=[Instruction: tlang.compiler.codegen.instruction.FetchValueVar:fetchVarValName: myVar, VarLen: 1], attemptCoerce=true): Leaving > core.exception.AssertError@source/tlang/compiler/typecheck/core.d(489): unittest failure > ---------------- > ??:? _d_unittestp [0x6700f1] > source/tlang/compiler/typecheck/core.d:489 void tlang.compiler.typecheck.core.TypeChecker.__unittest_L438_C5() [0x64d9c7] > ??:? void tlang.compiler.typecheck.core.__modtest() [0x6549fe] > ??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*) [0x690ae6] > ??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) [0x66653f] > ??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x67d08f] > ??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x67d5d5] > ??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x67d01d] > ??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x666511] > ??:? runModuleUnitTests [0x69091e] > ??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x678014] > ??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x677fa1] > ??:? _d_run_main2 [0x677f0a] > ??:? _d_run_main [0x677cf3] > /usr/include/dmd/druntime/import/core/internal/entrypoint.d:29 main [0x593151] > ??:? [0x7fcdca7e6b49] > ??:? __libc_start_main [0x7fcdca7e6c0a] > ??:? _start [0x5929a4] > 1/5 modules FAILED unittests > Error Program exited with code 1 > ``` > > Could be a case of a tets case that should now pass based on coercion. Fixed now ✅

deavmi stopped working 2023-07-07 11:10:56 +01:00

55 minutes 44 seconds

deavmi started working 2023-07-07 11:11:20 +01:00

deavmi commented

2023-07-07 11:11:42 +01:00

Working on adding support for standalone variable assignments now. That is to say, migrating to using typeEnforce()

Working on adding support for standalone variable assignments now. That is to say, migrating to using `typeEnforce()`

deavmi commented

2023-07-07 11:15:55 +01:00

Working on adding support for standalone variable assignments now. That is to say, migrating to using typeEnforce()

Done coding it ✅ - CI is good!

> Working on adding support for standalone variable assignments now. That is to say, migrating to using `typeEnforce()` Done coding it ✅ - CI is good!

deavmi stopped working 2023-07-07 11:16:09 +01:00

4 minutes 49 seconds

deavmi commented

2023-07-07 11:16:29 +01:00

Aight, will take little break now but gonna keep grinding this!

deavmi started working 2023-07-07 11:18:25 +01:00

deavmi commented

2023-07-07 11:21:06 +01:00

Migration to `typeEnforce()` v1

Basics

These don't need much thought as to how we want it done in TLang.

Variable declarations with assignments
Standalone variable assignments
Function call parameters (see #142)
- Array coercion integration

More thought

Binary operator
- Question: How do we determine the correct type
- Answer: We use biggerOfTheTwo(Integer integralType1, Integer integralType2) to determine the bigger one and then try coerce the smaller one to it!
- Also see issues #141

Questions ❓

We can emit stuff and hope that C then obviously provides widening and shortening but if we were to emit our own language that was a lowermlevel IR or VM code then we'd need to make those actions explicit. This isn't necessarily hard but typeEnforce() would need a third parameter (of type ref Instruction) which could dump the widening/shortening/conversion instructio which we need to save to the stack-queue too during code generation.

~~Another way we could make it explicit is by, instead of updating the types we make typeEnforce() NOT call setType() but rather emit a CastInstruction.~~

Completed with #137

Updates for `typeEnforce()` v1

Stack-array coercion support
- We need to add support for canCoerceStackArray(Type, Type, Type) - as required for function calls

## Migration to `typeEnforce()` v1 ### Basics These don't need much thought as to how we want it done in TLang. - [x] Variable declarations with assignments - [x] Standalone variable assignments - [x] Function call parameters (see #142) - [x] Array coercion integration ### More thought - [ ] Binary operator * **Question:** How do we determine the correct type * **Answer:** We use `biggerOfTheTwo(Integer integralType1, Integer integralType2)` to determine the bigger one and then try coerce the smaller one to it! * Also see issues #141 ## Questions ❓ ~~We can emit stuff and hope that C then obviously provides widening and shortening but if we were to emit our own language that was a lowermlevel IR or VM code then we'd need to make those actions explicit. This isn't necessarily hard but `typeEnforce()` would need a third parameter (of type `ref Instruction`) which could dump the widening/shortening/conversion instructio which we need to save to the stack-queue too during code generation.~~ ~~Another way we could make it explicit is by, instead of updating the types we make `typeEnforce()` **NOT** call `setType()` but rather emit a `CastInstruction`.~~ Completed with #137 ## Updates for `typeEnforce()` v1 - [x] Stack-array coercion support * We need to add support for `canCoerceStackArray(Type, Type, Type)` - as required for function calls

deavmi commented

2023-07-07 11:26:40 +01:00

Migration to typeEnforce()

Variable declarations with assignments

Standalone variable assignments

Function call parameters

It would seem one of the things we will need to do is to put code for array coercion to ptr and stack array to array coercion in our attemptCoercion() somewhere before we can do functions as it relies on those checks as part of its old isSameType, canStack...() code - the speghetti we are removing! :) 🍝

> ## Migration to `typeEnforce()` > > - [x] Variable declarations with assignments > - [x] Standalone variable assignments > - [ ] Function call parameters It would seem one of the things we will need to do is to put code for array coercion to ptr and stack array to array coercion in our `attemptCoercion()` somewhere before we can do functions as it relies on those checks as part of its old `isSameType`, `canStack...()` code - the speghetti we are removing! :) 🍝

deavmi stopped working 2023-07-07 11:27:09 +01:00

8 minutes 44 seconds

deavmi started working 2023-07-07 14:36:51 +01:00

deavmi stopped working 2023-07-07 14:50:37 +01:00

13 minutes 46 seconds

deavmi started working 2023-07-07 14:52:27 +01:00

deavmi stopped working 2023-07-07 14:52:30 +01:00

3 seconds

deavmi added a new dependency 2023-07-07 15:49:17 +01:00

#137 🧠️ Feature: type enforcer using CastInstruction emit

deavmi started working 2023-07-07 21:00:56 +01:00

deavmi stopped working 2023-07-07 21:00:58 +01:00

2 seconds

deavmi started working 2023-07-09 13:40:48 +01:00

deavmi commented

2023-07-09 13:43:06 +01:00

Synced with vardec_varass_depencency, no merge conflicts and CI/CD is all green ✅

Synced with `vardec_varass_depencency`, no merge conflicts and CI/CD is all green ✅

deavmi stopped working 2023-07-09 13:43:14 +01:00

2 minutes 26 seconds

deavmi commented

2023-07-09 13:58:24 +01:00

I will try finish this, this coming week - this is a very important feature and has already been added to the documentation so it MUST work.

It is just array stuff that remains (which needs to be incoprorated into typeEnforce()'s definition and also used in those places and also BinaryOp I believe.

I will try finish this, this coming week - this is a very important feature **and** has already been added to the documentation so it MUST work. It is just array stuff that remains (which needs to be incoprorated into `typeEnforce()`'s definition and also used in those places and also BinaryOp I believe.

deavmi referenced this issue

2023-07-09 14:18:26 +01:00

Type checking everything! #61

deavmi added a new dependency 2023-07-09 14:18:35 +01:00

#61 Type checking everything!

deavmi started working 2023-07-09 14:26:56 +01:00

deavmi stopped working 2023-07-09 14:30:28 +01:00

3 minutes 32 seconds

deavmi started working 2023-07-09 14:31:02 +01:00

deavmi stopped working 2023-07-09 14:31:05 +01:00

3 seconds

deavmi started working 2023-07-10 12:42:39 +01:00

deavmi commented

2023-07-10 12:43:22 +01:00

Lunch time! 🥪

Working on adding pointer coercion under certain circumstances...

This is part of the branch code for handling BinaryOperator expressions in doTypeCheck().

## Lunch time! 🥪 Working on adding pointer coercion under certain circumstances... 1. This is part of the branch code for handling `BinaryOperator` expressions in `doTypeCheck()`.

deavmi stopped working 2023-07-10 14:09:53 +01:00

1 hour 27 minutes

deavmi started working 2023-07-10 14:10:00 +01:00

deavmi added a new dependency 2023-07-10 14:10:07 +01:00

#140 Code gen: Casted pointer offets

deavmi referenced this issue

2023-07-10 14:10:24 +01:00

Code gen: Casted pointer offets #140

deavmi stopped working 2023-07-10 15:08:11 +01:00

58 minutes 11 seconds

deavmi started working 2023-07-10 15:13:46 +01:00

deavmi stopped working 2023-07-10 15:19:33 +01:00

5 minutes 46 seconds

deavmi commented

2023-07-10 20:23:34 +01:00

I am almost done (very sure I am done with actually) the changes I needed in #140 to continue (was emitted code getting ih the way).

See #140 for more information.

I am almost done (very sure I am done with actually) the changes I needed in #140 to continue (was emitted code getting ih the way). See #140 for more information.

deavmi started working 2023-07-11 08:55:23 +01:00

deavmi stopped working 2023-07-11 08:55:37 +01:00

13 seconds

deavmi added spent time 2023-07-11 09:04:20 +01:00

3 minutes

deavmi started working 2023-07-11 09:04:23 +01:00

deavmi commented

2023-07-11 09:05:17 +01:00

Migration to typeEnforce() v1

Basics

These don't need much thought as to how we want it done in TLang.

Variable declarations with assignments

Standalone variable assignments

Function call parameters

Array coercion integration

More thought

Binary operator

Question: How do we determine the correct type

Answer: We use biggerOfTheTwo(Integer integralType1, Integer integralType2) to determine the bigger one and then try coerce the smaller one to it!

Questions ❓

We can emit stuff and hope that C then obviously provides widening and shortening but if we were to emit our own language that was a lowermlevel IR or VM code then we'd need to make those actions explicit. This isn't necessarily hard but typeEnforce() would need a third parameter (of type ref Instruction) which could dump the widening/shortening/conversion instructio which we need to save to the stack-queue too during code generation.

~~Another way we could make it explicit is by, instead of updating the types we make typeEnforce() NOT call setType() but rather emit a CastInstruction.~~

Completed with #137

Updates for typeEnforce() v1

Stack-array coercion support
* We need to add support for canCoerceStackArray(Type, Type, Type) - as required for function calls

Working on the binary operator type enforcement again now.

> ## Migration to `typeEnforce()` v1 > > ### Basics > > These don't need much thought as to how we want it done in TLang. > > - [x] Variable declarations with assignments > - [x] Standalone variable assignments > - [ ] Function call parameters > - [ ] Array coercion integration > > ### More thought > > - [ ] Binary operator > * **Question:** How do we determine the correct type > * **Answer:** We use `biggerOfTheTwo(Integer integralType1, Integer integralType2)` to determine the bigger one and then try coerce the smaller one to it! > > ## Questions ❓ > > ~~We can emit stuff and hope that C then obviously provides widening and shortening but if we were to emit our own language that was a lowermlevel IR or VM code then we'd need to make those actions explicit. This isn't necessarily hard but `typeEnforce()` would need a third parameter (of type `ref Instruction`) which could dump the widening/shortening/conversion instructio which we need to save to the stack-queue too during code generation.~~ > > ~~Another way we could make it explicit is by, instead of updating the types we make `typeEnforce()` **NOT** call `setType()` but rather emit a `CastInstruction`.~~ > > Completed with #137 > > ## Updates for `typeEnforce()` v1 > > - [ ] Stack-array coercion support > * We need to add support for `canCoerceStackArray(Type, Type, Type)` - as required for function calls > > Working on the binary operator type enforcement again now.

deavmi stopped working 2023-07-11 09:06:37 +01:00

2 minutes 14 seconds

deavmi started working 2023-07-11 09:44:49 +01:00

deavmi stopped working 2023-07-11 10:13:58 +01:00

29 minutes 9 seconds

deavmi started working 2023-07-11 10:14:13 +01:00

deavmi stopped working 2023-07-11 10:19:10 +01:00

4 minutes 57 seconds

deavmi started working 2023-07-11 10:19:29 +01:00

deavmi added a new dependency 2023-07-11 11:02:27 +01:00

#141 Binary Operators support for non-Integer types

deavmi stopped working 2023-07-11 11:02:30 +01:00

43 minutes 1 second

deavmi added a new dependency 2023-07-11 11:02:36 +01:00

#142 Function parameter casts

deavmi added spent time 2023-07-11 17:28:45 +01:00

10 minutes

deavmi started working 2023-07-11 17:28:48 +01:00

deavmi stopped working 2023-07-11 17:29:10 +01:00

22 seconds

deavmi commented

2023-07-11 18:05:02 +01:00

Migration to typeEnforce() v1

Basics

These don't need much thought as to how we want it done in TLang.

Variable declarations with assignments

Standalone variable assignments

Function call parameters (see #142)

Array coercion integration

More thought

Binary operator

Question: How do we determine the correct type

Answer: We use biggerOfTheTwo(Integer integralType1, Integer integralType2) to determine the bigger one and then try coerce the smaller one to it!

Also see issues #141

Questions ❓

We can emit stuff and hope that C then obviously provides widening and shortening but if we were to emit our own language that was a lowermlevel IR or VM code then we'd need to make those actions explicit. This isn't necessarily hard but typeEnforce() would need a third parameter (of type ref Instruction) which could dump the widening/shortening/conversion instructio which we need to save to the stack-queue too during code generation.

~~Another way we could make it explicit is by, instead of updating the types we make typeEnforce() NOT call setType() but rather emit a CastInstruction.~~

Completed with #137

Updates for typeEnforce() v1

Stack-array coercion support
* We need to add support for canCoerceStackArray(Type, Type, Type) - as required for function calls

Function call stack array coercion seems to be working

> ## Migration to `typeEnforce()` v1 > > ### Basics > > These don't need much thought as to how we want it done in TLang. > > - [x] Variable declarations with assignments > - [x] Standalone variable assignments > - [x] Function call parameters (see #142) > - [x] Array coercion integration > > ### More thought > > - [ ] Binary operator > * **Question:** How do we determine the correct type > * **Answer:** We use `biggerOfTheTwo(Integer integralType1, Integer integralType2)` to determine the bigger one and then try coerce the smaller one to it! > * Also see issues #141 > > ## Questions ❓ > > ~~We can emit stuff and hope that C then obviously provides widening and shortening but if we were to emit our own language that was a lowermlevel IR or VM code then we'd need to make those actions explicit. This isn't necessarily hard but `typeEnforce()` would need a third parameter (of type `ref Instruction`) which could dump the widening/shortening/conversion instructio which we need to save to the stack-queue too during code generation.~~ > > ~~Another way we could make it explicit is by, instead of updating the types we make `typeEnforce()` **NOT** call `setType()` but rather emit a `CastInstruction`.~~ > > Completed with #137 > > ## Updates for `typeEnforce()` v1 > > - [ ] Stack-array coercion support > * We need to add support for `canCoerceStackArray(Type, Type, Type)` - as required for function calls > > Function call stack array coercion seems to be working

deavmi added spent time 2023-07-11 18:12:57 +01:00

10 minutes

deavmi started working 2023-07-11 20:06:19 +01:00

deavmi stopped working 2023-07-11 20:07:54 +01:00

1 minute 35 seconds

deavmi removed a dependency 2023-07-13 12:34:53 +01:00

#113 🐞️ Functions: Expressionless return and enforcing requirement

deavmi started working 2023-07-13 12:35:25 +01:00

deavmi commented

2023-07-13 12:36:09 +01:00

Completed #113 ✅

deavmi stopped working 2023-07-13 12:36:54 +01:00

1 minute 29 seconds

deavmi added a new dependency 2023-07-16 15:00:32 +01:00

#143 🐞 Bugfix: Ensure that typed functions contain a return statement

deavmi removed a dependency 2023-07-16 17:22:35 +01:00

#143 🐞 Bugfix: Ensure that typed functions contain a return statement

deavmi started working 2023-07-16 17:25:02 +01:00

deavmi stopped working 2023-07-16 17:25:06 +01:00

4 seconds

deavmi started working 2023-07-16 17:26:52 +01:00

deavmi commented

2023-07-16 17:28:33 +01:00

Just merged #143 into the vardec_varass_dependency, upstreaming into featuire/universal_coercion...

Just merged #143 into the `vardec_varass_dependency`, upstreaming into `featuire/universal_coercion`...

deavmi commented

2023-07-16 17:36:39 +01:00

Just merged #143 into the vardec_varass_dependency, upstreaming into featuire/universal_coercion...

Things are failing! ❗ ❗ ❗

CI/CD and test cases

Failing test cases

simple_function_recursion_factorial.t
- [ERROR] Function 'factorial' declared with return type does not contain a return statement

> Just merged #143 into the `vardec_varass_dependency`, upstreaming into `featuire/universal_coercion`... Things are failing! ❗ ❗ ❗ CI/CD **and** test cases ### Failing test cases - [x] `simple_function_recursion_factorial.t` * `[ERROR] Function 'factorial' declared with return type does not contain a return statement`

👍 1

deavmi stopped working 2023-07-16 17:44:16 +01:00

17 minutes 25 seconds

deavmi added a new dependency 2023-07-16 18:21:37 +01:00

#146 🐞 Bugfix: Recursively check for return statemen tprescence

deavmi started working 2023-07-16 18:21:40 +01:00

deavmi commented

2023-07-16 18:22:11 +01:00

Syncing now...

deavmi commented

2023-07-16 18:24:43 +01:00

Syncing now...

We now are getting a different error, type checking related probably (see https://github.com/tbklang/tlang/actions/runs/5568915900/jobs/10171880242?pr=9)

> Syncing now... We now are getting a different error, type checking related probably (see https://github.com/tbklang/tlang/actions/runs/5568915900/jobs/10171880242?pr=9)

deavmi commented

2023-07-16 18:26:17 +01:00

Syncing now...

We now are getting a different error, type checking related probably (see https://github.com/tbklang/tlang/actions/runs/5568915900/jobs/10171880242?pr=9)

Doesn't seem to be type checker related 🤔

> > Syncing now... > > We now are getting a different error, type checking related probably (see https://github.com/tbklang/tlang/actions/runs/5568915900/jobs/10171880242?pr=9) Doesn't seem to be type checker related 🤔

deavmi stopped working 2023-07-16 18:26:32 +01:00

4 minutes 52 seconds

deavmi started working 2023-07-16 18:30:26 +01:00

deavmi commented

2023-07-16 18:56:34 +01:00

Fixed it, was related to ReturnStmt checking in Parser (the last unit test)

CI/CD is ✅

So unit tests fine. Also fixed testcase simple_functions.t (upstreamed both this and the above unit test changes from vardec_varass_dependency) which had a missing return statement in the banana function.

Fixed it, was related to `ReturnStmt` checking in `Parser` (the last unit test) CI/CD is ✅ --- So unit tests fine. Also fixed testcase `simple_functions.t` (upstreamed both this and the above unit test changes from `vardec_varass_dependency`) which had a missing `return` statement in the `banana` function.

deavmi commented

2023-07-16 18:57:28 +01:00

Fixed it, was related to ReturnStmt checking in Parser (the last unit test)

CI/CD is ✅

So unit tests fine. Also fixed testcase simple_functions.t (upstreamed both this and the above unit test changes from vardec_varass_dependency) which had a missing return statement in the banana function.

I LIE! It is not all done, still got some failing tests.

> Fixed it, was related to `ReturnStmt` checking in `Parser` (the last unit test) > > CI/CD is ✅ > > --- > > So unit tests fine. Also fixed testcase `simple_functions.t` (upstreamed both this and the above unit test changes from `vardec_varass_dependency`) which had a missing `return` statement in the `banana` function. I LIE! It is not all done, still got some failing tests.

deavmi commented

2023-07-16 19:01:45 +01:00

Fixed it, was related to ReturnStmt checking in Parser (the last unit test)

CI/CD is ✅

So unit tests fine. Also fixed testcase simple_functions.t (upstreamed both this and the above unit test changes from vardec_varass_dependency) which had a missing return statement in the banana function.

I LIE! It is not all done, still got some failing tests.

Found another one, fixed it now. Same story - missing return statements.

This time it's all fixed for real ✅ ✅ ✅ ✅ ✅

> > Fixed it, was related to `ReturnStmt` checking in `Parser` (the last unit test) > > > > CI/CD is ✅ > > > > --- > > > > So unit tests fine. Also fixed testcase `simple_functions.t` (upstreamed both this and the above unit test changes from `vardec_varass_dependency`) which had a missing `return` statement in the `banana` function. > > I LIE! It is not all done, still got some failing tests. Found another one, fixed it now. Same story - missing `return` statements. This time it's all fixed for real ✅ ✅ ✅ ✅ ✅

deavmi stopped working 2023-07-16 19:10:17 +01:00

39 minutes 51 seconds

deavmi added spent time 2023-07-16 19:37:01 +01:00

1 minute

deavmi referenced this issue

2023-07-22 13:37:19 +01:00

Literal encodings #94

deavmi commented

2023-08-09 16:49:13 +01:00

I should finish this up this week and just go ahead and merge it. Any things requiring coercion can be fixed later, it's a very effortless migration.

deavmi started working 2023-08-10 18:41:36 +01:00

deavmi commented