[all-commits] [llvm/llvm-project] 90828d: [flang] Weird restrictions on index variables (#77...

[Peter Klausler via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 90828d67ea35c86b76fc8f3dec5da03f645eadaf
      https://github.com/llvm/llvm-project/commit/90828d67ea35c86b76fc8f3dec5da03f645eadaf
  Author: Peter Klausler <35819229+klausler at users.noreply.github.com>
  Date:   2024-01-15 (Mon, 15 Jan 2024)

  Changed paths:
    M flang/docs/Extensions.md
    M flang/include/flang/Common/Fortran-features.h
    M flang/lib/Semantics/resolve-names.cpp
    M flang/test/Semantics/dosemantics12.f90
    M flang/test/Semantics/forall01.f90
    M flang/test/Semantics/resolve35.f90
    M flang/test/Semantics/resolve99.f90
    M flang/test/Semantics/symbol09.f90

  Log Message:
  -----------
  [flang] Weird restrictions on index variables (#77019)

There are some very odd (even for Fortran) rules in F'2023 subclause
19.4 (paras 6 & 8) pertaining to the index variables of FORALL and DO
CONCURRENT constructs/statements, and they are not currently implemented
correctly.

Although these index variables are construct entities, they have
restrictions in the standard that would essentially allow them to also
be variables in their enclosing scopes. If their names are present in
the enclosing scope, and the construct does not have an explicit type
specification for its indices, then the names in the enclosing scope
must either be scalar variables or COMMON blocks, and their type must be
integer.

Reimplement these restrictions largely with portability warnings rather
than hard errors. Retain the semantic interpretation that the type of an
untyped index variable be taken from the type of a variable of the same
name in the enclosing scope, if it exists, although that bit of the
standard could be interpreted otherwise.

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