We need to retain carriage return characters in source files
that are not parts of multi-byte line endings; they are
significant in CHARACTER literal constants.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The FCVS test FM363 covers the issue. It would be helpful for the commit message to refer to the test.
The project is looking for volunteers to integrate and upstream this freely available Fortran test suite [1].
I see, but would it be hard to add such a unit test to the flang parser tests in tree? An external test suite is great, but most code should also be covered by unit-tests, unless it is not possible to do so.
Changing the topic a bit:
! In D83808#2152697, @fhahn wrote:
... An external test suite is great, ...
Are test suites in llvm-test-suite considered to be external?
Yes, I meant external to the llvm-project mono-repo. The tests in llvm-project are the first line of defense that developers use and IIUC they should exercise and test most of the code in llvm-projec It is also what most public buildbots run. For example, clang has an extensive test suite of the C/C++ parser in tree (https://github.com/llvm/llvm-project/tree/master/clang/test/Parser) , as well as benefiting from extensive external testing (bootstrap builds, llvm-test-suite and so on).
Given that the only public bot I am aware of (http://lab.llvm.org:8011/builders/flang-aarch64-ubuntu) only runs ninja check-all, it seems like good coverage of the flang parser (and other parts of flang) in tree would be quite important to catch regressions.
Of course there are cases that cannot be reasonably tested as tests in-tree, for example if the test would require very large input files. As I mentioned initially, I am not sure if this applies for a test for the issue this patch fixes.