b8bfe3586e
A specification expression can reference an implicitly declared variable in the host procedure. Because we have to process specification parts before execution parts, this may be the first time we encounter the variable. We were assuming the variable was implicitly declared in the scope where it was encountered, leading to an error because local variables may not be referenced in specification expressions. The fix is to tentatively create the implicit variable in the host procedure because that is the only way the specification expression can be valid. We mark it with the flag `ImplicitOrError` to indicate that either it must be implicitly defined in the host (by being mentioned in the execution part) or else its use turned out to be an error. We need to apply the implicit type rules of the host, which requires some changes to implicit typing. Variables in common blocks are allowed to appear in specification expressions (because they are not locals) but the common block definition may not appear until after their use. To handle this we create common block symbols and object entities for each common block object during the `PreSpecificationConstruct` pass. This allows us to remove the corresponding code in the main visitor and `commonBlockInfo_.curr`. The change in order of processing causes some different error messages to be emitted. Some cleanup is included with this change: - In `ExpressionAnalyzer`, if an unresolved name is encountered but no error has been reported, emit an internal error. - Change `ImplicitRulesVisitor` to hide the `ImplicitRules` object that implements it. Change the interface to pass in names rather than having to get the first character of the name. - Change `DeclareObjectEntity` to have the `attrs` argument default to an empty set; that is the typical case. - In `Pre(parser::SpecificationPart)` use "structured bindings" to give names to the pieces that make up a specification-part. - Enhance `parser::Unwrap` to unwrap `Statement` and `UnlabeledStatement` and make use of that in PreSpecificationConstruct. Differential Revision: https://reviews.llvm.org/D86322
35 lines
1.4 KiB
Fortran
35 lines
1.4 KiB
Fortran
! RUN: %S/test_errors.sh %s %t %f18
|
|
! Test BLOCK DATA subprogram (14.3)
|
|
block data foo
|
|
!ERROR: IMPORT is not allowed in a BLOCK DATA subprogram
|
|
import
|
|
real :: pi = asin(-1.0) ! ok
|
|
!ERROR: An initialized variable in BLOCK DATA must be in a COMMON block
|
|
integer :: notInCommon = 1
|
|
integer :: uninitialized ! ok
|
|
!ERROR: 'q' may not appear in a BLOCK DATA subprogram
|
|
procedure(sin), pointer :: q => cos
|
|
!ERROR: 'p' may not be a procedure as it is in a COMMON block
|
|
procedure(sin), pointer :: p => cos
|
|
common /block/ pi, p
|
|
!ERROR: An initialized variable in BLOCK DATA must be in a COMMON block
|
|
integer :: inDataButNotCommon
|
|
data inDataButNotCommon /1/
|
|
integer :: inCommonA, inCommonB
|
|
!ERROR: 'incommona' in COMMON block /a/ must not be storage associated with 'incommonb' in COMMON block /b/ by EQUIVALENCE
|
|
common /a/ inCommonA, /b/ inCommonB
|
|
equivalence(inCommonA, inCommonB)
|
|
integer :: inCommonD, initialized ! ok
|
|
common /d/ inCommonD
|
|
equivalence(inCommonD, initialized)
|
|
data initialized /2/
|
|
integer :: inCommonE, jarr(2)
|
|
equivalence(inCommonE, jarr(2))
|
|
!ERROR: 'incommone' cannot backward-extend COMMON block /e/ via EQUIVALENCE with 'jarr'
|
|
common /e/ inCommonE
|
|
equivalence(inCommonF1, inCommonF2)
|
|
integer :: inCommonF1, inCommonF2
|
|
!ERROR: 'incommonf1' is storage associated with 'incommonf2' by EQUIVALENCE elsewhere in COMMON block /f/
|
|
common /f/ inCommonF1, inCommonF2
|
|
end block data
|