Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge developer branch #1543

Merged
merged 20 commits into from
Mar 5, 2025
Merged

Merge developer branch #1543

merged 20 commits into from
Mar 5, 2025

Conversation

EmelyanenkoK
Copy link
Member

No description provided.

SpyCheese and others added 20 commits February 13, 2025 14:25
1) Liteserver queries count
2) Collated/validated blocks count, number of active sessions
3) Persistent state sizes
4) Initial sync progress
* add option to build static tonlibjson and emulator

* do not export cmake project in case of static tonlibjson
In FunC (and in Tolk before), the assignment
> lhs = rhs
evaluation order (at IR level) was "rhs first, lhs second".
In practice, this did not matter, because lhs could only
be a primitive:
> (v1, v2) = getValue()
Left side of assignment actually has no "evaluation".
Since Tolk implemented indexed access, there could be
> getTensor().0 = getValue()
or (in the future)
> getObject().field = getValue()
where evaluation order becomes significant.

Now evaluation order will be to "lhs first, rhs second"
(more expected from user's point of view), which will become
significant when building control flow graph.
This commit introduces nullable types `T?` that are
distinct from non-nullable `T`.
Example: `int?` (int or null) and `int` are different now.
Previously, `null` could be assigned to any primitive type.
Now, it can be assigned only to `T?`.

A non-null assertion operator `!` was also introduced,
similar to `!` in TypeScript and `!!` in Kotlin.

If `int?` still occupies 1 stack slot, `(int,int)?` and
other nullable tensors occupy N+1 slots, the last for
"null precedence". `v == null` actually compares that slot.
Assigning `(int,int)` to `(int,int)?` implicitly creates
a null presence slot. Assigning `null` to `(int,int)?` widens
this null value to 3 slots. This is called "type transitioning".

All stdlib functions prototypes have been updated to reflect
whether they return/accept a nullable or a strict value.

This commit also contains refactoring from `const FunctionData*`
to `FunctionPtr` and similar.
With the introduction of nullable types, we want the
compiler to be smart in cases like
> if (x == null) return;
> // x is int now
or
> if (x == null) x = 0;
> // x is int now

These are called smart casts: when the type of variable
at particular usage might differ from its declaration.

Implementing smart casts is very challenging. They are based
on building control-flow graph and handling every AST vertex
with care. Actually, I represent cfg not a as a "graph with
edges". Instead, it's a "structured DFS" for the AST:
1) at every point of inferring, we have "current flow facts"
2) when we see an `if (...)`, we create two derived contexts
3) after `if`, finalize them at the end and unify
4) if we detect unreachable code, we mark that context
In other words, we get the effect of a CFG but in a more direct
approach. That's enough for AST-level data-flow.

Smart casts work for local variables and tensor/tuple indices.
Compilation errors have been reworked and now are more friendly.
There are also compilation warnings for always true/false
conditions inside if, assert, etc.
In FunC (and in Tolk before) throwing an exception is just
calling a built-in function:
> throw 123; // actually, __throw(123)
Since it's a regular function, the compiler was not aware
that execution will stop, and all following code is unreachable.
For instance, `throw` in the end on function needed to be
followed by `return` statement.

Now, `throw` interrupts control flow, all statements after
it are considered unreachable. At IR level, code Ops are
also not produced.

This works because a built-in __throw() now has `never` type.
It can also be applied to custom functions:
> fun alwaysThrow(): never { throw 123; }
The code after alwaysThrow() call will also be unreachable.
* fix docker github build (Segmentation fault (core dumped) dpkg: error processing package libc-bin (--configure))

* fix docker github build (Segmentation fault (core dumped) dpkg: error processing package libc-bin (--configure))

* update gh qemu actions

* run on ubuntu 24.04

* try driver-opts: image=moby/buildkit:v0.11.0

* split docker images for amd64 and arm64

* Revert "split docker images for amd64 and arm64"

This reverts commit 609617f.

* clean libc-bin
Tolk v0.9: nullable types `T?`, null safety, control flow, smart casts
@ton-blockchain ton-blockchain deleted a comment from soheilbarakt Mar 5, 2025
@EmelyanenkoK EmelyanenkoK merged commit 0439613 into master Mar 5, 2025
21 of 26 checks passed
Copy link

@spboy777 spboy777 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5

Copy link

@HamiAlyasin54 HamiAlyasin54 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

پیدات کردم حالا حساب منو خالی میکنی و میزنی به چاک اشغال عوضی

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants