Ondřej Čertík

Excellent. 16% is very good, it shouldn't be hard to get to 100%.

@mottelet yes, we definitely want to compile all those old codes.

See https://github.com/lfortran/lfortran/issues/4431 for the WASM failure.

Awesome. I think this is great, thanks for fixing it. Go ahead and fix the small things per my comments above and we can merge it.

I see, apparently gfortran also will give an error message: ``` $ gfortran a.f90 a.f90:32:4: 32 | main_arr%arr_2%num = 22 | 1 Error: Two or more part references with nonzero...

Great catch! Thanks! If you could please submit a PR to fix this, that would be very helpful.

Also let's add a test at the CI, that we used to have at GitLab: * https://gitlab.com/lfortran/lfortran/-/blob/master/ci/parser.yy.patch * https://gitlab.com/lfortran/lfortran/-/blob/master/ci/grammar_conflicts.sh I thought that we don't need this, that we'll just do...

Thanks to @swamishiju, the following diff removes all conflicts: ```diff --- a/src/lfortran/parser/parser.yy +++ b/src/lfortran/parser/parser.yy @@ -3,9 +3,7 @@ %define api.value.type {LCompilers::LFortran::YYSTYPE} %param {LCompilers::LFortran::Parser &p} %locations -%glr-parser -%expect 232 // shift/reduce...

We now test this at the CI: https://github.com/lfortran/lfortran/pull/8215.

Here are the relevant parts of the Bison grammar: ```bison /* The first common block specification in a COMMON statement does not need "//" to represent blank common. Enumerating all...