List-directed child input is allowed to advance to new records in some
circumstances, and list-directed output should be as well so that e.g.
NAMELIST output via a defined WRITE(FORMATTED) generic doesn't get
truncated by FORT_FMT_RECL.

Fixes https://github.com/llvm/llvm-project/issues/166804.

Whether list-directed child READ statements should be allowed to advance
to further records is neither explicit in the standard nor consistent in
existing Fortran implementations. We allow child namelist READ
statements to advance, but not other list- directed child input.

This patch refines our interpretation of this case. Child namelist READ
statements continue to be able to advance; in addition, non-namelist
child READ statements can now advance if their parent READ statement is
a list-directed input statement at the top level, or a child that could.
But non-namelist list-directed child input taking place in a context
with explicit format control won't advance to following records, so that
the format-controlled parent READ statement can retain control over
record advancement.

Also corrects two cases of record repositioning in numeric input
editing, which were failing under child input because they weren't
allowing for left tab limits.

Fixes https://github.com/llvm/llvm-project/issues/160351.

…tion

When scanning list-directed input for nulls and repetition counts, the
current library depends on having each record be prescanned for the
presence of asterisk characters. It turns out that the overhead of
calling memchr(...,'*',...) on each record doesn't pay off, especially
on systems without SIMD-vectorized memchr implementations -- even on
those, it's faster (about 10%) to just scan ahead for asterisks when
decimal digits are encountered. Only when an asterisk is present, which
is not common, should we then bother to convert the digits to their
integer value.

Child list-directed input needs to inherit and return the state used to
process trailing separators (eatComma_) and terminal '/' (hitSlash_)
from any parent list-directed input statement.

Fixes https://github.com/llvm/llvm-project/issues/157509 and
https://github.com/llvm/llvm-project/issues/154971.

When somebody replaced uses of std::optional<> in the runtime with a new
optional<> defined locally, many needless top-level Fortran:: namespace
qualifiers were added, which are inconsistent with namespace usage in
the runtime. Clean them up.

NAMELIST input in child I/O is rare, and it's not clear in the standard
whether it should be allowed to advance to later records in the parent
unit. But GNU Fortran supports it, and there's no good reason not to do
so since a NAMELIST input group that isn't terminated on the same line
is otherwise going to be a fatal error.

Fixes https://github.com/llvm/llvm-project/issues/153416.

When an OPEN statement has specifiers that are allowed only for
formatted files, detect an error when the file turns out to be
unformatted.

Fixes https://github.com/llvm/llvm-project/issues/153480.

The various per-type functions for list-directed (including namelist)
input editing all call a common function to detect whether the next
token of input is the name of a namelist item. This check simply
determines whether this next token looks like an identifier followed by
'=', '(', or '%', and this fails when the next item of input is a NAN
with parenthesized stuff afterwards. Make the check smarter so that it
ensures that any upcoming possible identifier is actually the name of an
item in the namelist group. (And that's tricky too when the group has an
array item named "nan" and the upcoming input is "nan("; see the
newly-added unit test case.)

Fixes https://github.com/llvm/llvm-project/issues/152538.

more

When NAMELIST input takes place on a derived type, we need to preserve
the type in the descriptor that is created for storage sequence
association. Further, the fact that any child list input in within the
context of a NAMELIST must be inherited so that input fields don't try
to consume later "variable=" strings.

Fixes https://github.com/llvm/llvm-project/issues/151222.

As a common extension, we support the truncation of fixed-width fields
for non-list-directed input editing when a separator character (',' or
';' depending on DECIMAL='POINT' or 'COMMA' resp.) appears in the field.
This isn't working for L input editing; fix.

(The bug reports a failure with DC mode, but it doesn't work with a
comma either.)

Fixes https://github.com/llvm/llvm-project/issues/151178.