Problem with `lfc` parsing C++.

[stustd]

I might have a potential problem with lfc parsing C++ code in the CCpp target. In a method I have the following C++ snippet using raw string syntax:

// mset with TTL
auto mset_with_ttl_script = R"(
        local len = #KEYS
        if (len == 0 or len + 1 ~= #ARGV) then return 0 end
        local ttl = tonumber(ARGV[len + 1])
        if (not ttl or ttl <= 0) then return 0 end
        for i = 1, len do redis.call("SET", KEYS[i], ARGV[i], "EX", ttl) end
                return 1
        )";

Compiling with lfc returns the error:

lfc: error: mismatched character '\n' expecting '"'
  --> /home/stdstd/projects/ot/lf/src/OT.lf:384:42
    |
383 |             // mset with TTL
    | >>>>>>>>>>>>>>
384 |             auto mset_with_ttl_script = R"(
385 |                 local len = #KEYS
    | < mismatched character '\n' expecting '"'
386 |                 if (len == 0 or len + 1 ~= #ARGV) then return 0 end
v

A stripped problem version, i.e.

lfc: error: mismatched character '\n' expecting '"'
  --> /home/stdstd/projects/ot/lf/src/OT.lf.lf:503:20
    |
502 | 
    | >>>>>>>>>>>>>>
503 |          auto a = R"(A
504 |          B
    | < mismatched character '\n' expecting '"'
505 |          )";

lfc: error: mismatched character '\n' expecting '"'

makes me believe that lfc has problems parsing multiline raw strings .... So I'm not sure if this an lfc parser or c++ compiler error (I'm using gnu g++-12)?

[lhstrh]

Could you please share a minimal example of a problematic .lf file so we can reproduce the problem?

[stustd]

Could you please share a minimal example of a problematic .lf file so we can reproduce the problem?

A minimal example (lf_CCpp_parsing.lf):

target CCpp

preamble {=

  // comment this out and `lfc` will compile
  const char* a = R"(
  Hello
  )";

=}

main reactor lf_CCpp_parsing {}

Hope this helps.

[lhstrh]

I fixed it in https://github.com/lf-lang/lingua-franca/pull/2385. I expect there are more corner cases that we're not handling correctly, but the root of the problem is that we're parsing what's in between {= =} delimiters at all. We shouldn't, but Xtext isn't quite flexible enough for our needs, and our workaround has its limitations...

[stustd]

"We shouldn't, but ..." Indeed, there's no reason for it. Thanks for the fix. And let me use the occasion to express my respect and gratitude for the impressive LF technology!

[lhstrh]

Thanks, @stustd. And please keep the bug reports coming!