-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[flang][OpenMP] Parse ORDERED as standalone when DEPEND/DOACROSS is p… #156693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,5 @@ | ||
| ! RUN: not %flang_fc1 -fsyntax-only -fopenmp %s 2>&1 | FileCheck %s | ||
|
|
||
| !$omp parallel | ||
| ! CHECK: error: Expected OpenMP end directive | ||
| !$omp parallel | ||
| ! CHECK: error: Expected OpenMP END PARALLEL directive | ||
| end |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will now cause a parser error: "expected END". It's not very descriptive, but it's the same message for all unmatched end directives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we could continue the pattern of parsing approximately and then generating better errors in semantics. Here we could allow stray OmpEndDirective as an OpenMPConstruct (lowest priority). I spent some time messing with it but while I could detect the error condition in parsing, I didn't find a sufficiently non-hacky way to print the error message because the parser doesn't distinguish between "this didn't parse" and "there is an error here".
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made a couple of attempts to detect a "stray" end directive in the parser, but none of them worked. I've concluded that we'd need to use some form of the recovery parser to make sure the diagnostic message is printed. The recovery parser takes two parser arguments: (1) the "normal" parser, and (2) the parser that tries to do the recovery when (1) fails. When (2) succeeds, the parser is in recovery mode, the parsing continues, but will fail eventually because of the failure of (1).
When we parse parser::Block (i.e. a list of executable constructs), we rely on the fact that it will stop when it gets something that is not an executable construct. For us an end-directive fulfills that role: we parse "block", then, when that's done, we expect the end-directive. However, if we put the recovery parser in place, it will be invoked (from inside of the block parser) when an end-directive is encountered. So the block parsing won't just end gracefully on an end directive, it will hit the recovery parser and fail every single time. So that is clearly not good...
One more thing I want to try was to parse parser::Block "manually" with preemptively checking for an end directive, i.e. something like
This way we will always handle all the expected end directives by ourselves. The recovery parser would only see the misplaced ones.