Malformed asm functions pass Tact compiler but fail during FunC compilation stage

[Shvandre]

Are you using the latest released (or pre-released, a.k.a. "next") version?

• I'm using the latest Tact version

Tact source code

import "@stdlib/deploy";

asm fun myCode(): Cell { "MYCODE" }

contract Sample {
    mycode: Cell;
    init() {
        self.mycode = myCode();
    }
}

Relevant Tact/build system log output

yarn run v1.22.22
$ tact --config ./tact.config.json
💼 Compiling project sample ...
   > Sample: tact compiler
   > Sample: func compiler
Func compilation error: /home/b4cksl4sh/TON-Studio/tact-template/sources/output/sample_Sample.code.fc:13:47: error: string extends past end of line
  cell $global_myCode() impure asm """"MYCODE"""";
💥 Compilation failed. Skipping packaging
error Command failed with exit code 30.

What happened?

No response

What did you expect?

As asm functions are declared in funC in "", it might be the common mistake. Maybe tact compiler should check that? Or change the format of asm functions, because static analizers are mad at them.

Steps to reproduce

No response

How do you run Tact?

tact-template

Anything else?

No response

[novusnota]

This is (partially) fixed in the current dev version of the compiler. What I mean by partially, is that this code compiles in both Tact and FunC (no string errors there).

But the actual error happens in Fift, where it sees the "MYCODE" and, as expected, treats it as a Slice. Which means that this is a logical issue rooted in the intents of the developer coming from FunC to Tact. And I don't know how to treat that, apart from the docs saying that Tact does not need strings.

UPD: Maybe, we can either prohibit strings there during the parsing. Should be fine, since FunC allows to use Fift's "..." syntax only in its multiline strings.

[novusnota]

The actual error output in the latest dev compiler version looks like this:

[novusnota]

Maybe, we can either prohibit strings there during the parsing

Well, I've just finished a long series of attempts to do just that, and it really messes our general parsing flow, disallowing to parse things like "Asm.fif" include or preventing "x{" from being defined, etc.. So the generic solutions do not cut it.

Perhaps, some rather specific might do, like just look for /^"[A-Z]+"$/, such as "MYCODE" or "NOP". That's a marginal improvement, but an improvement nonetheless

UPD: Nope! Such words are defined too, so that fails.