Page MenuHomePhabricator

[flang] Checks for constraints C741 through C750

Authored by PeteSteinfeld on Apr 14 2020, 3:09 PM.



Most of these checks were already implemented, and I just added references to
them to the code and tests. Also, much of this code was already
reviewed in the old flang/f18 GitHub repository, but I didn't get to
merge it before we switched repositories.

I implemented the check for C747 to not allow coarray components in derived
types that are of type C_PTR, C_FUNPTR, or type TEAM_TYPE.

I implemented the check for C748 that requires a data component whose type has
a coarray ultimate component to be a nonpointer, nonallocatable scalar and not
be a coarray.

I implemented the check for C750 that adds additional restrictions to the
bounds expressions of a derived type component that's an array. C750 prohibits
specification functions, the intrinsic functions ALLOCATED, ASSOCIATED,
EXTENDS_TYPE_OF, PRESENT, and SAME_TYPE_AS. It also requires every
specification inquiry reference to be a constant expression, and requires that
the value of the bound not depend on the value of a variable.

I changed the implementation of IsPureProcedure() to handle statement functions
and changed some references in the code that tested for the PURE attribute to
call IsPureProcedure().

I also fixed some unrelated tests that got new errors when I implemented these
new checks.

Diff Detail

Event Timeline

PeteSteinfeld created this revision.Apr 14 2020, 3:09 PM
Herald added a project: Restricted Project. · View Herald Transcript
tskeith added a project: Restricted Project.Apr 14 2020, 3:19 PM
lebedev.ri retitled this revision from Checks for constraints C741 through C750 to [flang] Checks for constraints C741 through C750.Apr 14 2020, 3:22 PM
PeteSteinfeld edited the summary of this revision. (Show Details)Apr 14 2020, 3:26 PM
PeteSteinfeld edited the summary of this revision. (Show Details)Apr 14 2020, 3:28 PM
tskeith added inline comments.Apr 14 2020, 3:57 PM

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 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?


If symbol is a statement function it must have SubprogramDetails. So you can use symbol.get<SubprogramDetails>() instead.


Why is "when an allocatable object is a coarray" here but not in the TEAM_TYPE message?


Why '%goodcoarrayfield' rather than 'goodcoarrayfield'?


There is an extra space between "coarray" and "ultimate".

sscalpone added inline comments.Apr 14 2020, 5:08 PM

+1 an addition to the intrinsics table

PeteSteinfeld marked 5 inline comments as done.Apr 15 2020, 8:48 AM
PeteSteinfeld added inline comments.

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.


Thanks. I'll change that.


Good question. I'll make the two messages consistent.


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.


Thanks. I'll fix that.

tskeith requested changes to this revision.Apr 20 2020, 1:48 PM
This revision now requires changes to proceed.Apr 20 2020, 1:48 PM
DavidTruby resigned from this revision.Apr 22 2020, 6:52 AM
PeteSteinfeld updated this revision to Diff 260345.EditedApr 27 2020, 8:38 AM

I changed the test to see if a function is in intrinsic inquiry function from a
string comparison to a more general capability in the intrinsic proc table to
get the intrinsic class of a procedure.

I changed the test for intrinsics specific that are prohibited from use
specifically in derived type component bound declarations to be a set of

I changed the implementation of IsPureProcedure() to get the associated
symbol's SubprogramDetails to check for references to PURE procedures and
VOLATILE variables.

I made the error messages for bad declarations of derived type components to be
more consistent.

I removed the "%" in front of the component name in error messages relating to
bad component declarations.

I noticed that C750 prohibits non-constant specification inquiries and added a
test for specification inquiries that are type parameter inquiries which are
defined in 9.4.5. I added a test for this case, which caused me to change the
implementation of "IsConstantExpr()" for "TypeParamInquiry"s and symbols.
Specifically, I now require that individual parts of a "TypeParamInquiry" to be
constant. I also call a component of a derived type constant since the overall
"constant"ness of the expression will be determined by the enclosing derived
type object.

In the process of implementing this, I noticed that we really need a predicate
function to determine if an expression is a specification inquiry as defined in
10.1.11(5). But I decided to defer the implementation of such a predicate to

tskeith added inline comments.Apr 27 2020, 2:39 PM

Are the changes to this file intentional? They don't seem related to your changes.

tskeith edited the summary of this revision. (Show Details)Apr 28 2020, 11:07 AM
PeteSteinfeld marked an inline comment as done.Apr 29 2020, 9:35 AM
PeteSteinfeld added inline comments.

I changed the implementation of "IsConstantExpr" in lib/Evaluate/check-expression.cpp to say that symbols that are components are constants. That change caused this test to emit different error messages for these two cases.

Previously, a symbol was only declared as a constant if it had the PARAMETER attribute or was an implied DO index. My reasoning is that the derived type object establishes whether the expression is constant. The problem I was trying to solve is that we were always treating expressions like "a%b" as non-constant even if "a" was a constant.

tskeith accepted this revision.Apr 29 2020, 10:03 AM
This revision is now accepted and ready to land.Apr 29 2020, 10:03 AM
sscalpone accepted this revision.Apr 30 2020, 8:18 AM
PeteSteinfeld abandoned this revision.May 1 2020, 2:09 PM

This review is superseded by D79263.