Forbid comparing null with non-optional type

[Gusarich]

Closes #570

• I have updated CHANGELOG.md
• I have documented my contribution in Tact Docs: https://github.com/tact-lang/tact-docs/pull/PR-NUMBER
• 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 have run the linter, formatter and spellchecker
• I did not do unrelated and/or undiscussed refactorings

[Gusarich]

Seems that __tact_load_address_opt is being used for optional addresses even though the type of the field might be not nullable

[Gusarich]

It seems that currently Address type can be null by default even without marking it with ? sign and simply refers to addr_none:

tact/src/test/e2e-emulated/contracts/sample-jetton.tact

Line 69 in 4ce02f2

if (msg.response_destination != null) { // Cashback

I believe that this is wrong behavior and null should only be allowed in nullable types marked with ?, e.g. Address?.

We should probably move this one to 1.5.0 because resolving this will require adding or changing some functionality related to work with addresses.

[anton-trunov]

We should probably move this one to 1.5.0 because resolving this will require adding or changing some functionality related to work with addresses.

It's ok to change things if this fixes a bug

[Gusarich]

Actually, after investigating this issue a bit further I understood that there are no bugs in optional addresses and __tact_load_address_opt is only used when the address is optional.

The reason for test fail is that they were originally wrong - response_destination on the line I mentioned above is always not null but there is still a comparison.

So to finish with this PR and #570 we can just fix the SampleJetton test case, and get back to #515 (comment) in the next release.

[anton-trunov]

So to finish with this PR and #570 we can just fix the SampleJetton test case, and get back to #515 (comment) in the next release.

let's go for it

[anton-trunov]

@Gusarich I fixed some edge cases with void types and refactored the implementation a bit, please have a look. Maybe you can break it or add new test cases

[Gusarich]

@Gusarich I fixed some edge cases with void types and refactored the implementation a bit, please have a look. Maybe you can break it or add new test cases

Looks good!