Implement constant string receivers

[Gusarich]

Closes #51

• I have updated CHANGELOG.md
• I have added tests to demonstrate the contribution is correctly implemented: this usually includes both positive and negative tests, showing the happy path(s) and featuring intentionally broken cases
• I have run all the tests locally and no test failure was reported
• I did not do unrelated and/or undiscussed refactorings

[Gusarich]

just found out it doesn't work correctly for contract-scoped constants. I'll fix that

[Gusarich]

Fixed.
However, there's a temporary limitation on lvalue paths. I had to add it because #284 and #400 aren't resolved yet.
We'll be able to support strings from constant structs after these are resolved.

[Gusarich]

Rebased, added more tests and implemented handling constant values from structs.
Also found #439 during testing.

[anton-trunov]

Great progress!

Let's add some more tests:

• a positive test: a constant definition in a trait that is used as a receiver name;
• a negative test with a trait constant declaration, so it does not have a body.

[anton-trunov]

This is a case of "receiver not found", right? Not a duplicate one, because string3 is missing

[anton-trunov]

It feels like the following constant look-up code should be factored out into a helper function. This also should be implemented for expressions as well, can't we reuse that code here?

[anton-trunov]

Btw, the constant lookup you have implemented here, should go to the constant evaluator:

tact/src/constEval.ts

Line 521 in 9ed9193

export function evalConstantExpression(

. So, after typechecking the receiver constant string, you just run const-eval on it and you should get your string. This way you will also extend the supported language fragment for const-eval and resolve issue #229.

[anton-trunov]

We could even allow arbitrary expressions in receivers as long as those are string-valued constant expressions

[Gusarich]

This way we'll try to evaluate a constant that might depend on the resolved contract during resolving that same contract. With static constants it'll work fine, but with cases like receive(self.something) it won't work...

[anton-trunov]

Why not? We can first process all constants and then process receivers

[Gusarich]

Because these are stored in CompilerContext with the contract itself in the very end of the resolving:

tact/src/types/resolveDescriptors.ts

Lines 1622 to 1624 in 9ed9193

	for (const [k, t] of types) {
	ctx = store.set(ctx, k, t);
	}

So I can't get contract-scoped constants by calling getAllTypes or getType in constant evaluator.

[anton-trunov]

if we cannot move it before receiver processing stage, let's just push this PR to v1.5 and solve this properly

[anton-trunov]

Let's actually change stringLiteral to Expression here (and for externals) to support arbitrary expressions: it should work as long as it's a string-valued constant expression. In the future we might have some compile-time string builtins or even allow integers, so instead of doing this:

message(1) OpCodeOneNoData {}

contract Contract {
  // would be nice to support underscores here too, since OpCodeOneNoData does not carry any further info
  receive(f: OpCodeOneNoData) {
      self.reply("OpCodeOneNoData".asComment())
  }
}

one could do

contract Contract {
  receive(1) {
      self.reply("OpCodeOneNoData".asComment())
  }
}

[novusnota]

Hmm, interestingly enough it would somewhat change receivers towards #433. I'd propose having arbitrary string-valued expressions specified in constant declarations somewhere on top, or generally just prior to receivers and not embedded in. Motivation here reflects what you've said there: #433 (comment)

That said, @Gusarich would have the last word here :)

[anton-trunov]

yeah, it's a bit too late to have a consistent design for Tact v1.x :) given that we already have messages and strings