Casting support #87

New Issue

deavmi · 2023-01-14T10:38:34Z

deavmi commented

2023-01-14 10:38:34 +00:00

What is this?

We want to add support for a cast(<type>, <expression>) or maybe cast(<type>)<expression> keyword such that we can easily change types. This will probably require some sort of new object to be made, like a CastedExpression that wraps an existing expression of some sorts. Therefore the type can be persisted? Or something, we need to look at how we want to go about it.

### What is this? We want to add support for a `cast(<type>, <expression>)` or maybe `cast(<type>)<expression>` keyword such that we can easily change types. This will probably require some sort of new object to be made, like a `CastedExpression` that wraps an existing expression of some sorts. Therefore the type can be persisted? Or something, we need to look at how we want to go about it.

deavmi added this to the Basics milestone 2023-01-14 10:46:15 +00:00

deavmi self-assigned this 2023-01-14 10:46:19 +00:00

deavmi added the

typing

parser

labels 2023-01-14 10:46:30 +00:00

deavmi added this to the Parser project 2023-01-14 10:46:33 +00:00

deavmi added reference casting

2023-01-14 10:46:38 +00:00

deavmi commented

2023-01-14 10:49:33 +00:00

Example

Given a code like below:

int j = 1;
byte f = j;

We would have a mismatch.

Firstly the second line would push a FetchValueInstr: j onto the codequeue, and onto the type queue we would have int. We would therefore need to then do something like we have below:

int j = 1;
byte f = cast(byte)j;

This would mean we would firstly have a unary operator (called cast), and with this we would have on the codequeue FetchValueVar: j, then processing the CastUnaryOp would pop it off and embed it into a CastUnaryInstr (instead of a normal UnaryOpInstr) - it should be a sub-type probably.
Then processing it we should pop the type (and really check if it is impossible, but anyways then continue) and then push the type fo the requested type onto the typequeue.
Now, I don't think everything would be able to unpacka CastedFetchInstruction or whatever, so should we do a little hack where we don;t push a CastedFetchInstruction onto the stack or what? I think the type situation is what matters most, but this instruction must be a value instruction and then ...
I think during emit, we effectively will hoist the .getEmbeddedValueInstr() from the CastedInstruction suhc that we can perform that actual instruction and then we perform an emit for casting it (think movb etc. on lowest byte of an int).

## Example Given a code like below: ```d int j = 1; byte f = j; ``` We would have a mismatch. Firstly the second line would push a `FetchValueInstr: j` onto the codequeue, and onto the type queue we would have `int`. We would therefore need to then do something like we have below: ```d int j = 1; byte f = cast(byte)j; ``` 1. This would mean we would firstly have a unary operator (called cast), and with this we would have on the codequeue `FetchValueVar: j`, then processing the `CastUnaryOp` would pop it off and embed it into a `CastUnaryInstr` (instead of a normal `UnaryOpInstr`) - it should be a sub-type probably. 2. Then processing it we should pop the type (and really check if it is impossible, but anyways then continue) and then push the type fo the requested type onto the typequeue. 3. Now, I don't think everything would be able to unpacka `CastedFetchInstruction` or whatever, so should we do a little hack where we don;t push a `CastedFetchInstruction` onto the stack or what? I **think** the type situation is what matters most, but this instruction must be a value instruction and then ... 4. I think during emit, we effectively will hoist the `.getEmbeddedValueInstr()` from the `CastedInstruction` suhc that we can perform that **actual** instruction _and then_ we perform an emit for casting it (think movb etc. on lowest byte of an int).

deavmi added the due date 2023-01-31

2023-01-14 11:00:38 +00:00

deavmi commented

2023-01-14 16:43:20 +00:00

Progress

Basic code emit of correct type with commit 113386ebe2a6cf72b60767fa239b69a8d8ea217d on branch casting

module simple_cast;

int myInt;

void function()
{
    byte bruh;
    byte myByte = (cast(byte)myInt)+bruh;
}

The above code works correctly (and finds a type error when doing +myIntinstead ofbruh`). However, without braces on the cast operator, it doesn't complain, we may need to look at that.

Investigate the above precedence things

## Progress - [x] Basic code emit of correct type with commit `113386ebe2a6cf72b60767fa239b69a8d8ea217d` on branch `casting` ```d module simple_cast; int myInt; void function() { byte bruh; byte myByte = (cast(byte)myInt)+bruh; } ``` The above code works correctly (and finds a type error when doing +myInt` instead of `bruh`). However, without braces on the cast operator, it doesn't complain, we may need to look at that. - [ ] Investigate the above precedence things

deavmi commented

2023-01-15 10:57:09 +00:00

Merging the latest commit of bbb9aaaa515be96748756a4bfae0e6c237e86429 on branch casting into varass now.
I want to merge the commit 2c912132492b4e3674dd44b2f128fd84727e9ebe of pointers into varass now too.
Then merge varass into pointers and casting to have them up to date and deduplicate.

All done ✅

- [x] Merging the latest commit of `bbb9aaaa515be96748756a4bfae0e6c237e86429` on branch `casting` into `varass` now. - [x] I want to merge the commit `2c912132492b4e3674dd44b2f128fd84727e9ebe` of `pointers` into `varass` now too. - [x] Then merge `varass` into `pointers` and `casting` to have them up to date and deduplicate. **All done** ✅

deavmi referenced this issue

2023-04-14 11:56:27 +01:00

Casting improvement, parseTypedDeclaration() #110

deavmi commented

2023-04-17 15:37:45 +01:00

This was also improved by #110 - just an FYI 🪄

deavmi referenced this issue

2023-04-17 21:06:16 +01:00

Casting improvement, parseTypedDeclaration() #110

deavmi added a new dependency 2023-04-20 10:20:24 +01:00

#110 Casting improvement, parseTypedDeclaration()

deavmi referenced this issue