Since commit 219a9b1e14 (Fortran: Fix suprious dependencies with
submodules, 2022-07-30, v3.25.0-rc1~327^2) we accidentally fail to
recognize `end interface X`, causing all subsequent modules to be seen
as an interface.
Fixes: #24203
In commit 695f0d0d3a (cmFortranParser: Parse keywords as lexical tokens,
2016-09-05, v3.7.0-rc1~150^2) we created keyword-specific variants of
the original `USE WORD other EOSTMT` production, such as
`MODULE WORD other EOSTMT` and `INTERFACE WORD other EOSTMT`. The same
pattern was used by more keyword-specific productions in commit b5ac8b8aa7
(Fortran: Add support for submodule syntax in dependency scanning,
2016-09-05, v3.7.0-rc1~73^2~1).
The postfix part (`other`) of several keyword-specific productions is
not needed to match Fortran syntax. See the Fortran 2018 standard,
para.4.1.4/1 on p.28, para.14.2.1/2 on pp.293-294. The postfix is
needed only for a case of operator 'use':
use <module-name> [, only : <list-of-vars>]
The unnecessary postfix matching from the keyword-specific productions
such as module, submodule, and interface declarations can cause spurious
module dependencies to be detected, so remove it.
Extend the test suite with examples covering the previously-broken
cases.
Fixes: #18427
Since commit v3.7.0-rc1~73^2~1 (Fortran: Add support for submodule
syntax in dependency scanning, 2016-09-05) we support parsing Fortran
sources that use submodule syntax, but it left addition of `.smod`
dependencies to future work. Add it now.
The syntax
submodule (module_name) submodule_name
means the current source requires `module_name.mod` and provides
`module_name@submodule_name.smod`. The syntax
submodule (module_name:submodule_name) nested_submodule_name
means the current source requires `module_name@submodule_name.smod`
provides `module_name@nested_submodule_name.smod`.
Fixes: #17017
Brad King