Check for constrains C741 through C749 by psteinfeld · Pull Request #1100 · flang-compiler/f18

psteinfeld · 2020-04-04T02:16:16Z

Most of these checks were already implemented and I just added references to
them to the code and tests.

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 also fixed some unrelated tests that got new errors when I implemented these
new checks.

This change is

Most of these checks were already implemented and I just added references to them to the code and tests. 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 also fixed some unrelated tests that got new errors when I implemented these checks.

tskeith · 2020-04-07T14:48:44Z

+          "Coarray components must be ALLOCATABLE and have a deferred "
+          "coshape"_err_en_US);


I don't think the message should say "and have a deferred coshape" unless it doesn't have a deferred coshape.

Or just combine the tests and use the second message, it's got all the information.

Thanks, Tim. I'll change the code to remove that phrase when it doesn't apply.

@klausler, I think it's a little confusing to have the message tell the user that the declaration must have a deferred coshape when it already has one. I plan to stick with Tim's suggestion.

tskeith · 2020-04-07T14:57:35Z

-! C736: If EXTENDS appears and the type being defined has a coarray ultimate
-! component, its parent type shall have a coarray ultimate component.


Where is the test for C736 now?

C736 is specific to the definition of a component of a derived type, and all of the tests in allocate11.f90 were allocate statements. I added the test resolve86.f90 in my previous pull request to cover the case of defining a component that contains a coarray ultimate component without having a parent type that contains a coarray ultimate component. This may have happened after you reviewed and approved that pull request.

tskeith · 2020-04-07T15:06:38Z

+    !ERROR: 'pointerfield' may not have the POINTER attribute because it is a coarray
+    !ERROR: Coarray components must be ALLOCATABLE and have a deferred coshape


It would be nice if the wording of these two messages were similar. For example, the second could be:
Component 'pointerfield' must have the ALLOCATABLE attribute because it is a coarray

Sounds good. I'll change it.

tskeith · 2020-04-07T15:08:02Z

+      if (FindCoarrayUltimateComponent(*derived)) { // C748
+        if (attrs.HasAny({Attr::POINTER, Attr::ALLOCATABLE})) {
+          Say("A component whose type has a coarray ultimate component "
+              "cannot be a POINTER or ALLOCATABLE"_err_en_US);


We have mostly been using "may not" rather than "cannot".

I also use "must not", but I shouldn't -- "may" is the correct modal verb here, since we're talking about what's allowed, not what might be possible.

You might as well capture the result of FindCoarrayUltimateComponent and use its name in the message and link to its declaration.

Thanks. I'll fix it.

I notice that there are many uses of the word "cannot" in resolve-names.cpp. @tskeith, should I fix them all in this pull request?

I think it makes more sense to change them in a separate pull request, but if you want to do it in this one that's okay too.

I think I'll wait.

klausler

All of these constraints on coarrays really could have been expressed more simply in the standard, and maybe it would be easier on the user in some cases if we explicitly stated in messages what the standard only implies -- a coarray can't be part of any array, and can't be a local variable other than a dummy argument or (I think) something that's SAVE. In implementation terms, every coarray that isn't a dummy argument has -- or can have -- a fixed static address set at link time. But I can't think of a good way to use that simple statement in a way that would improve the messages; maybe you can.

klausler · 2020-04-07T16:10:32Z

+          "Coarray components must be ALLOCATABLE and have a deferred "
+          "coshape"_err_en_US);


Or just combine the tests and use the second message, it's got all the information.

klausler · 2020-04-07T16:14:21Z

+          "coshape"_err_en_US);
    } else {
-      if (!details.coshape().IsAssumedSize()) { // C828
+      if (!details.coshape().IsAssumedSize()) { // C746, C828


C746 applies to components, but components are all handled earlier.

Good catch! This also applies to the comment above. I'll remove the spurious references.

klausler · 2020-04-07T16:16:52Z

+              "ISO_FORTRAN_ENV"_err_en_US);
+        } else {
+          if (IsIsoCType(derived)) {
+            Say("A coarray component may not be of C_PTR or C_FUNPTR from "


Missing the word "type", or needs rewording.

Thanks for catching this. I'll fix it.

klausler · 2020-04-07T16:19:00Z

+      if (FindCoarrayUltimateComponent(*derived)) { // C748
+        if (attrs.HasAny({Attr::POINTER, Attr::ALLOCATABLE})) {
+          Say("A component whose type has a coarray ultimate component "
+              "cannot be a POINTER or ALLOCATABLE"_err_en_US);


I also use "must not", but I shouldn't -- "may" is the correct modal verb here, since we're talking about what's allowed, not what might be possible.

You might as well capture the result of FindCoarrayUltimateComponent and use its name in the message and link to its declaration.

I redid the error messages for violations of C746 to be more consistent and customized them so that we don't complain unnecessarily about deferred coshapes. I removed some spurious references to C746. I fixed the error message for coarray components of type C_PTR or C_FUNPTR. I added an attachment to the messages relating to ultimate components to point to the relevant declarations. I fixed the tests to match the message changes in the code and added another test for components that are allocatable coarrays that do not have a deferred coshape.

tskeith · 2020-04-07T23:25:55Z

+      if (auto it{FindCoarrayUltimateComponent(*derived)}) { // C748
+        Message declMsg{Say(it->name(),
+            "Type '%s' has coarray ultimate component '%s' declared here"_en_US,
+            declType->AsFortran(), it.BuildResultDesignatorName())};


Does this work correctly if the coarray component is declared in a module that is read in from a .mod file?

coarray ultimate components to use the function AttachDeclaration() to output the declaration of the derived type that contains the associated coarray ultimate component.

psteinfeld requested review from klausler and tskeith April 4, 2020 02:16

tskeith reviewed Apr 7, 2020

View reviewed changes

klausler reviewed Apr 7, 2020

View reviewed changes

tskeith reviewed Apr 7, 2020

View reviewed changes

I redid the code that produced error messages for components with

57b82a9

coarray ultimate components to use the function AttachDeclaration() to output the declaration of the derived type that contains the associated coarray ultimate component.

		"Coarray components must be ALLOCATABLE and have a deferred "
		"coshape"_err_en_US);

		! C736: If EXTENDS appears and the type being defined has a coarray ultimate
		! component, its parent type shall have a coarray ultimate component.

		!ERROR: 'pointerfield' may not have the POINTER attribute because it is a coarray
		!ERROR: Coarray components must be ALLOCATABLE and have a deferred coshape

Conversation

psteinfeld commented Apr 4, 2020 • edited by tskeith Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

klausler left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

psteinfeld commented Apr 4, 2020 •

edited by tskeith

Loading