This is an archive of the discontinued LLVM Phabricator instance.

[flang] Support correct continuations for compiler directives
ClosedPublic

Authored by unterumarmung on May 24 2022, 7:16 AM.

Details

Summary

If a line is over 72 characters long, flang's preprocessor cuts it there
and continues on the next line.
For this purpose it uses the standard way of continuing line with & on each line.
However, it doesn't work with long compiler directives, like OpenMP or OpenACC ones.
The line that continues the directive also has to
contain the corresponding sentinel at the beginning.

This change implements the described functionality.
Also, some code was refactored in order to simplify and reuse existing code.

Diff Detail

Event Timeline

unterumarmung created this revision.May 24 2022, 7:16 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
unterumarmung requested review of this revision.May 24 2022, 7:16 AM

Reviewers take note: this patch changes how some directive lines are *emitted* in the fake preprocessed output, *not* how they are processed in the prescanner.

flang/lib/Parser/parsing.cpp
126

Why?

184

Always use braced initialization in the parts of f18 that use modern C++.

unterumarmung added inline comments.May 24 2022, 8:26 AM
flang/lib/Parser/parsing.cpp
126

I extracted this code to a lambda from the existing code you've written a while ago.
Why I did this?

  1. I thought it'd be nice to have the same-cased sentinel for the continuation as the original directive's sentinel, so I used this function for the implementation of this functionality. IIRC, it is not strictly necessary, though.
  2. If we ignore the first point, IMHO extracting this code to a lambda increases readability of the code below.

Does this answer your question or there are things left to clarify?

184

Yes, sure.. It's hard for me to get used to always using the braced initialization. Will fix.

Address review comment: use brace initialization

klausler added inline comments.May 24 2022, 9:01 AM
flang/lib/Parser/parsing.cpp
99

Why not use IsLetter()?

109

Don't use unsigned ints when regular ints will work just fine. Also, please use braces in the parts of f18 written in modern C++ -- braced initialization provides stronger safety checking. And this is a case where auto probably isn't the most readable choice.

130

Why not use ToUpperCaseLetter()?

184

Braced initialization is safer; thanks.

unterumarmung marked 3 inline comments as done and an inline comment as not done.

Address review comments, fix encountered bug, add test case for the bug

flang/lib/Parser/parsing.cpp
99

Didn't know about this function, will fix

109

Forgot to change this one to the braced initialization, sorry
IDK why I chose unsigned int here - agree that simple int here is fine
Will fix!

130

This was your code initially, so I didn't change anything here intentionally. Also, I didn't know such function exists in the codebase.
The suggestion is nice, will fix!

@klausler, could you please take another look to the revision?
I tested the change on an internal codebase and found a bug: exclamation marks in string literals were treated as compiler directive beginnings. So, this lead to wrong behavior when a string literal "exceeded" 72 character limit.
It wasn't the problem before because there were no special logic for compiler directives.
The error was not detected with the test suite, so I added a test case for such occasion.

I think that you need a test case with long CHARACTER literals and Hollerith literals that contain the comment marker ('!').

Or (as a suggestion) treat the comment marker ('!') as such only when it appears as the first non-blank character of an output line.

flang/lib/Parser/parsing.cpp
139

You also need to handle Hollerith literals.

Changed the logic for identifying compiler directives, added Hollerith literals to the test

I think that you need a test case with long CHARACTER literals and Hollerith literals that contain the comment marker ('!').

Yeah, totally forgot about it, thanks!

Or (as a suggestion) treat the comment marker ('!') as such only when it appears as the first non-blank character of an output line.

It is actually a nice suggestion! I thought about it too, but for some reason thought that it'd be harder to implement than the solution with quotation marks.
Adding to this handling Hollerith literals would be such a mess. So, I implemented your suggestion and it is as simple as it possibly can be.

@klausler, I'm sorry, could you please take a look?

klausler accepted this revision.May 26 2022, 9:23 AM
This revision is now accepted and ready to land.May 26 2022, 9:23 AM