Compiler Milestone 2: More realistic FT subset

[SupunS]

The goal of this milestone is to support most of the language features needed for the FT transfer transaction and contracts.

FT (everything expect closures)

Preview Give feedback

1. Default functions - @SupunS
2. Pre-/post-conditions (difficult, complex, e.g. linking/chaining, default functions, linearization, etc.) - @SupunS
3. before function in post conditions - @SupunS [Compiler] Support compilation for before statements #3763
4. Casting (force-casting as!; Optional casting as? doesn’t seem necessary, but maybe also implement while at it) - @SupunS [Compiler] Support basic casting operations in VM #3767
5. Event emission (simple, try to reuse infrastructure (e.g. export) of runtime) @turbolent
6. If-let (for FlowToken) @turbolent
7. Switch statement (for FlowToken metadata standard impl.) @turbolent
8. Dictionary literal (compile + add VM instruction; replicate what we have for arrays) @turbolent
9. Comparison operators (<, ≤, etc.) @turbolent @SupunS
10. Fixed-point literal (compile to constant pool + load) #3762
    +0
    
11. Fixed-point numbers (UFix64 for balance of Vault; wait until interpreter refactor)
12. for-loop statement @SupunS
13. Double check we are erroring for unimplemented functionality in compiler
14. Re-enable compiler tests #3758
    Technical Debt +1
    
15. Conditional returns compilation #3772
    +0

Not needed:

• Entitlements: purely static
• Swap statement
• Assignment with second value

[turbolent]

@SupunS We might also want to add scoping to the list, as there are a few TODOs in the compiler for that

[turbolent]

@jsproz Can you please add your name to the item(s) you're working on? That way we can avoid accidental duplicate work. Thank you!

[SupunS]

We might also want to add scoping to the list, as there are a few TODOs in the compiler for that

I wasn't sure if we actually need any scoping at the compiler level, other than functions. Didn't run into any case where we would need such. So left those alone for now. Maybe we can create an issue, but might not actually need to do anything there, and all it need could be to clean-up the TODO s.

[bluesign]

one item I saw (I know you didnt implement yet scoping but as a note ) function argument shadowing and interface post conditions I saw recently when playing with your PR.

[turbolent]

@SupunS Not sure, but from what I can see, it looks like all comparison operators (<, ≤, etc.) are already implemented in the compiler and the VM. Was there anything left to be done there?

[SupunS]

@turbolent I had added those operators for Int type along with the default function generation (6ac49ca), because it was needed in some of the tests.

So what's left is to support the same for other numeric types / or make the existing opcode generic. But maybe that can wait till we port the number values?

[turbolent]

@SupunS Ah, I see! It looks like at the moment we only have a basic Int type, and once we have added the other numeric value types, we can generalize support for them.

To begin with, we can maybe make the int* arithmetic instructions polymorphic and have them work for all integer types (e.g. have IntAdd work for Int, UInt, Int8, etc.)?

Later we can optimize this and add dedicated sets of instructions for each type (UIntAdd, Int8Add, etc.). I feel like that's just a lot of code we need to add for little gain.

[SupunS]

Yeah, agree! Having a dedicated instruction for each type would be an overkill. Given NumberValue interface in the interpreter already support these operations, maybe we can follow the same here, and have just one instruction for all number values (e.g: NumericAdd/NumberAdd).