The production for a bare file unit number in an I/O statement checks
that the scalar integer expression isn't followed by "=", in order to
disambiguate FLUSHN from FLUSHN=1, and to not treat a control specifier
keyword as an integer expression. The implementation of this check used
!"="_tok, which has the side effect of producing no error message; this
can lead to a parsing crash later when a failed parse of an erroneous
program is found to have produced no errors. Rewrite as a lookAhead call
for those characters that acually can follow a bare unit number.
Fixes https://github.com/llvm/llvm-project/issues/105779.
An attempt to use an edit descriptor (other than A or L) in a FORMAT
statement without arequired 'w' width will elicit warnings from both
the parser and the I/O checker in semantics. Remove the warning from
the parser.
Differential Revision: https://reviews.llvm.org/D155977
Begin upstreaming of CUDA Fortran support in LLVM Flang.
This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps
... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.
Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.
More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.
Differential Revision: https://reviews.llvm.org/D150159
When a multi-statement construct should end with a particular END statement
like "END SELECT", and that construct's END statement is missing or
unrecognizable, the error recovery productions should not misinterpret
a program unit END statement that follows and consume it as a misspelled
construct END statement. Doing so leads to cascading errors or a failed parse.
Differential Revision: https://reviews.llvm.org/D136896
In free form source, pedantic mode will elicit portability warnings
about missing spaces when a token string ends with a character that
can be in an identifier and there is no space between that last token
character and a following character that can also be part of an identifier.
This behavior doesn't really work well for the token strings that are
parsed for edit descriptors in FORMAT statements. For example, the
'F' in FORMAT(F7.3) is followed by a digit, but obviously no space is
necessary. Free form or not, FORMATs are their own odd little world.
This patch adds trailing blanks to these FORMAT edit descriptor token
parsers to disable the missing space check, and extends the documentation
for token string parsing to explain why this technique works.
Differential Revision: https://reviews.llvm.org/D129023
Extend "extension<LanguageFeature>()" to incorporate an explanatory
message better than the current generic "nonstandard usage:".
Differential Revision: https://reviews.llvm.org/D122035
The parsing of I/O units uses look-ahead to discriminate between
keywords, variables and expressions as part of distinguishing internal
from external I/O. The look-ahead was inaccurate for variables that
appear as the initial parts of expressions.
Differential Revision: https://reviews.llvm.org/D95743
READ(CVAR)[,item-list] with a character variable CVAR
could be parsed as an unformatted READ from an internal
unit or as a formatted READ from the default external unit
with a needlessly parenthesized variable format. We parse
it as the former, but Fortran doesn't have unformatted
internal I/O.
Differential revision: https://reviews.llvm.org/D90493
