Testing LFortran's parser and formatter

We just released a new version of LFortran 0.11.0. You can install it using Conda:

conda create -n test1 lfortran=0.11.0
conda activate test1

Or you can compile from source. Our GSoC student @ThirumalaiShaktivel has done a tremendous job fixing every bug that we knew about in the parser and we tested it on quite a few codes. Now it’s a good time for the wider community to test it out. If you discover any bugs, please report them here or create an issue at: Issues · lfortran / lfortran · GitLab.

How to test:

lfortran fmt some_file.f90

If it prints the code back (in color), it works. If you get any kind of errors, it’s a bug in the compiler and we would appreciate it if you let us know about it. You can also replace the original file by lfortran fmt -i some_file.f90 (be careful, only do this if the original file is checked into git). If you compile the reformatted code with another Fortran compiler, it should compile and run correctly.

We are aware of the following issues, that we will fix soon:

  • comments are currently skipped (this includes pragmas like openmp)
  • empty lines are skipped
  • the location information can sometimes be incorect in AST (so when you get a syntax error, the line/column number might not be accurate)

If you discover anything else, please let us know.

13 Likes

Thanks, this is really cool. I just went ahead and tested it on all my Fortran source with

for i in $(fd '\.f90$' .); do lfortran fmt $i > /dev/null || echo $i; done

It seems to get most of the source I was throwing at it. Already started reporting at the issue tracker for the failures I encountered.

2 Likes

I had difficulty to install from source tar ball. I got a cmake error as below, not sure what it relates to.

cmake -DWITH_LLVM=yes -DCMAKE_INSTALL_PREFIX=/usr/local .
ZLIB_INCLUDE_DIR: /usr/include
ZLIB_LIBRARY: /usr/lib/libz.a
CMake Error at cmake/FindZLIB.cmake:7 (add_library):
add_library cannot create imported target “p::zlib” because another target
with the same name already exists.
Call Stack (most recent call first):
/usr/lib64/cmake/llvm/LLVMConfig.cmake:220 (find_package)
CMakeLists.txt:83 (find_package)

Thank you everybody, I woke up this morning and saw 12 new bugs to fix!

https://gitlab.com/lfortran/lfortran/-/issues?label_name=Parser

and two more issues with the formatter (Issues · lfortran / lfortran · GitLab). We’ll fix them soon.

3 Likes

I think this error was fixed by @awvwgk recently (Use CMake's built-in zlib finder (!1044) · Merge requests · lfortran / lfortran · GitLab). There is no FindZLIB.cmake file anymore. Can you try to use the 0.11.0 release? Either latest master or the source tarball from Download - LFortran. Also, make sure you use LLVM version 11, not 12. We have not upgraded to LLVM 12 yet.

Btw, to just test the parser and formatter, you don’t need LLVM so you can compile with -DWITH_LLVM=no.

Thanks. I tried 0.11.0 release. CMake is OK, but make failed

[ 55%] Building CXX object src/lfortran/CMakeFiles/lfortran_lib.dir/codegen/llvm_array_utils.cpp.o

In file included from /home/XX/lfortran-0.11.0/src/lfortran/codegen/evaluator.cpp:44:
/home/XX/lfortran-0.11.0/src/lfortran/codegen/KaleidoscopeJIT.h:22:10: fatal error: llvm/ExecutionEngine/Orc/LambdaResolver.h: No such file or directory
22 | #include “llvm/ExecutionEngine/Orc/LambdaResolver.h”
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [src/lfortran/CMakeFiles/lfortran_lib.dir/build.make:496: src/lfortran/CMakeFiles/lfortran_lib.dir/codegen/evaluator.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs…
make[1]: *** [CMakeFiles/Makefile2:317: src/lfortran/CMakeFiles/lfortran_lib.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

1 Like

I think you are using LLVM 12. You have to use LLVM 11, we have not ported to LLVM 12 yet. Or compile without LLVM, see above how to do it.

In my case the lfortran package could not be found (probably I would have to update the conda channels first):

$ conda create -n test1 lfortran=0.11.0
Collecting package metadata (current_repodata.json): done
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed

PackagesNotFoundError: The following packages are not available from current channels:

  - lfortran=0.11.0

...

However a two-step procedure (1 - create environement, 2 - install package) worked:

$ conda create -n test1
$ conda activate test1
$ conda install -c conda-forge lfortran 
2 Likes

@certik would it be complicated to provide single file binaries for end-users for all typical platforms (like it is currently done for fpm) to lower the barrier?

1 Like

Or you can do in one step:

conda create -n test1 -c conda-forge lfortran
conda activate test1

Yes, I forgot to add to use conda-forge. It is enabled by default for me.

It would not be complicated — in fact we already do precisely that for Linux, you can find the latest one here:

lfortran-0.11.0-59-g9fec843b · Artifacts · cxx_binary (#1426090202) · Jobs · lfortran / lfortran · GitLab

But I have not tested it for this release yet. If anyone wants to help us set this up for macOS and Windows also, we would really appreciate it.

2 Likes

Fantastic, thank you. I’m a Linux user, I will try it as soon as I can.

1 Like

Please report any bugs. Here is the place that builds it:

Here is the relevant part of the CMake build system that builds the binary tarball using cpack:

I think the binary is not tested at the CI, so we should add a test for it (to unpack it and run some example say in the latest Ubuntu docker image) and then we should set it up to upload somewhere and link to it at Download - LFortran, just like we handle source tarballs there already.

The lfortran binary worked really well out of the box (i.e. extract and run). Thanks!

I have uncovered a couple of bugs that I have reported on GitLab, as instructed.

2 Likes

I saw them, thank you! Thanks also for trying it.

1 Like

I have tried a simple test program in both lfortran terminal and jupyter notebook. On terminal, the Enter to submit is awkward. People usually use Enter to make a new line in source file. On jupyter, running a cell once is ok, but the 2nd time raises “semantic error: Program already defined”

I have limited time to try it, but I made a script to pull all registered fpm packages and then use lfortran as the compiler via a little wrapper script and flag actual errors and eliminated obvious duplicates. Generally looked very promising, but had a few interesting outputs using -i on all the packages that might be related to these files with actual failures so just bundled these up in a tar file first. I am sure some are still duplicates, but I think it will still be useful, as that is the result of thousands of files from a good number of authors using significantly different programming styles (so even there is a decent number here it is quite good, and a higher percentage succeeded than with ifx, but that is not quite fair because ifx does not do BLOCK yet and allocatable CHARACTER arrays of allocatable length, which was the majority of ifx(1) issues, as that is commonly used in this set):

wget http://www.urbanjost.altervista.org/REMOVE/lfortran_error.tgz 
#or
curl --output lfortran_error.tgz http://www.urbanjost.altervista.org/REMOVE/lfortran_error.tgz 

hopefully I will have time to do this a little more formally as bug reports but that will be a while and I think this will be useful now(?).

Thanks for trying it! What key would you find more natural to submit the cell? IPython, Python and Julia also use Enter I believe, so we used the same key. But we can change it.

You probably tried a program. Yes, we have to make redefinitions work still. In this thread I am only asking to test the parser, not the rest of the compiler, as we are still working on implementing enough features before we release the MVP. You can test the parser with lfortran fmt.

Awesome, thank you @urbanjost! Note that the gcp.f90 is already fixed in master, but some of the other ones still don’t work. We’ll fix it soon. @ThirumalaiShaktivel, would you mind please taking the tarball and reporting all errors in there? It contains a list of .f90 files that failed with the last release.

1 Like

Great it that was useful, fmt_i.tgz in the same directory might be useful, although I admit I have not looked through it yet myself. It is the before and after copies of the files that compiled before reformatting with “-i” but did not after. At least one of them has to do with a discussion I had in the past about unary operators and complex constants (changing “(-3.0, 4.0)” to “(-(3.0),4.0)” ) is non-standard. Who would have thought?

PS:
making a _scratch directory and pulling all the fpm(1) packages using fpm-search is pretty straight-forward, and gives you a lot of tests already in git(1). I use that a lot for testing fpm(1).
What is a kluge but handy is to create an “lf” compiler command and using it as the compiler on the packages on the fpm(1) command. You want it to keep going on an error. On a ULS if you make a little bash(1) script like

#!/bin/bash
##################################################
#@(#) call lfortran for formatting and keep going on error
##################################################
(
   FILE=$2
   echo ">>>>lfortran $FILE fmt"
   case "$FILE" in
   *dependencies/*);;
   *.f90|*.F90) 
      # create ANSI color version
      (lfortran fmt $FILE >$FILE.txt|| echo "OUCH $FILE")|xargs
      # actually replace the files with reformatted version
      #(lfortran fmt -i $FILE || echo "OUCH $FILE")|xargs
   ;;
   esac
)
#######################################
exit 0
#######################################

you can do a lot of tests, skipping the .c and .f files and not stopping on error. Interesting for testing compilers and fpm or looking for examples of usage

1 Like