[PATCH] D78160: [flang] Checks for constraints C741 through C750

[Pete Steinfeld via Phabricator via llvm-commits]

PeteSteinfeld marked 5 inline comments as done.
PeteSteinfeld added inline comments.
Herald added a reviewer: DavidTruby.


================
Comment at: flang/lib/Evaluate/check-expression.cpp:248
+            "rank same_type_as shape size storage_size tiny ubound ucobound"};
+        if (inquiryIntrinsics.find(intrin.name) != std::string::npos &&
+            !IsConstantExpr(x)) {
----------------
sscalpone wrote:
> tskeith wrote:
> > This test and the one above only work if there are no other intrinsics that can be returned by `GetSpecificIntrinsic` whose names are not substrings of one of the names in the string. For example, if `intrin.name` is "max", it will find it in `inquiryIntrinsics`.
> > 
> > It seems like a set would be a better representation than a string. Or maybe an addition to the intrinsics table?
> +1 an addition to the intrinsics table
Good point.  Certainly a set would be better.  I'll look into adding a couple of methods to the intrinsics table to cover these two cases.


================
Comment at: flang/lib/Semantics/tools.cpp:277
+    const SubprogramDetails *funcDetails{symbol.detailsIf<SubprogramDetails>()};
+    if (funcDetails) {
+      const MaybeExpr &expr{funcDetails->stmtFunction()};
----------------
tskeith wrote:
> If symbol is a statement function it must have SubprogramDetails. So you can use `symbol.get<SubprogramDetails>()` instead.
Thanks.  I'll change that.


================
Comment at: flang/test/Semantics/resolve88.f90:49
+  type c_ptrCoarrayType
+    !ERROR: A coarray component may not be of type C_PTR or C_FUNPTR from ISO_C_BINDING when an allocatable object is a coarray
+    type(c_ptr), allocatable, codimension[:] :: field
----------------
tskeith wrote:
> Why is "when an allocatable object is a coarray" here but not in the TEAM_TYPE message?
Good question.  I'll make the two messages consistent.


================
Comment at: flang/test/Semantics/resolve88.f90:67
+    type(coarrayType) :: goodField
+    !ERROR: A component with a POINTER or ALLOCATABLE attribute may not be of a type with a coarray ultimate component (named '%goodcoarrayfield')
+    type(coarrayType), pointer :: pointerField
----------------
tskeith wrote:
> Why '%goodcoarrayfield' rather than 'goodcoarrayfield'?
The "%" is meant to indicate that the name is the name of a component.  The code to create this message relies on the function "BuildResultDesignatorName()", which inserts the "%".  I assume that the other uses of this function are creating compound names that include the name of the derived type object followed the "%" and the field name.  I wasn't sure how to treat this.  This "%" adds a little information in that it is a hint that the name is a component name, but as both you and I noticed, it's also confusing.  I'll get rid of it.


================
Comment at: flang/test/Semantics/resolve88.f90:71
+    type(coarrayType), allocatable :: allocatableField
+    !ERROR: An array or coarray component may not be of a type with a coarray  ultimate component (named '%goodcoarrayfield')
+    type(coarrayType), dimension(3) :: arrayField
----------------
tskeith wrote:
> There is an extra space between "coarray" and "ultimate".
Thanks.  I'll fix that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78160/new/

https://reviews.llvm.org/D78160