diff options
| author | Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com> | 2025-09-25 07:58:57 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-09-25 07:58:57 -0500 |
| commit | d73ffe57f983c8ef9490e420d972ae3373b3f175 (patch) | |
| tree | 883a40a99ffe7c0eff4e121de7f75b724206c2c1 /libcxx/include/__algorithm | |
| parent | b7e20c741451bb846e25c87a782d746c2382597a (diff) | |
| download | llvm-d73ffe57f983c8ef9490e420d972ae3373b3f175.zip llvm-d73ffe57f983c8ef9490e420d972ae3373b3f175.tar.gz llvm-d73ffe57f983c8ef9490e420d972ae3373b3f175.tar.bz2 | |
[flang][OpenMP] Introduce variant argument, customize OmpArgument par… (#160372)
…sing
The DECLARE_VARIANT directive takes two names separated by a colon as an
argument: base-name:variant-name. Define OmpBaseVariantNames to
represent this, since no existing argument alternative matches it.
However, there is an issue. The syntax "name1:name2" can be the argument
to DECLARE_VARIANT (if both names are OmpObjects), but it can also be a
reduction-specifier if "name2" is a type. This conflict can only be
resolved once we know what the names are, which is after name resolution
has visited them. The problem is that name resolution has side-effects
that may be (practically) impossible to undo (e.g. creating new symbols,
emitting diagnostic messages).
To avoid this problem this PR makes the parsing of OmpArgument
directive- sensitive: when the directive is DECLARE_VARIANT, don't
attempt to parse a reduction-specifier, consider OmpBaseVariantNames
instead. Otherwise ignore OmpBaseVariantNames in favor of
reduction-specifier.
Diffstat (limited to 'libcxx/include/__algorithm')
0 files changed, 0 insertions, 0 deletions
