This is an archive of the discontinued LLVM Phabricator instance.

[flang] Constraint checks C751 to C760
ClosedPublic

Authored by PeteSteinfeld on May 12 2020, 11:29 AM.

Details

Summary

Many of these were already implemented, and I just annotated the tests and/or
the code.

C752 was a simple check to verify that CONTIGUOUS components are arrays with
the POINTER attribute.

C754 proved to be virtually identical to C750 that I implemented previously.
This caused me to remove the distinction between specification expressions for
type parameters and bounds expressions that I'd previously created.
the POINTER attribute.

C756 checks that procedure components have the POINTER attribute.

Diff Detail

Event Timeline

PeteSteinfeld created this revision.May 12 2020, 11:29 AM
Herald added a project: Restricted Project. · View Herald Transcript
PeteSteinfeld added a project: Restricted Project.May 12 2020, 11:53 AM
PeteSteinfeld edited the summary of this revision. (Show Details)May 12 2020, 11:54 AM
klausler requested changes to this revision.May 12 2020, 1:34 PM
klausler added inline comments.
flang/lib/Semantics/check-declarations.cpp
157

?

287

Why two if statements?

flang/lib/Semantics/resolve-names.cpp
3916

Can't this constraint be checked in check-declarations.cpp? If so, keep it out of name resolution.

3922

Just return here, and remove the Boolean.

flang/test/Semantics/resolve33.f90
42

This error seems spurious to me. We know that l (lower-case letter ell) is a type parameter.

This revision now requires changes to proceed.May 12 2020, 1:34 PM
tskeith added inline comments.May 12 2020, 3:15 PM
flang/test/Semantics/resolve33.f90
42

Yes, the "Must be a constant value" error too. The real errors are the ones above: "No definition found for type parameter".

Setting and checking the Error flag on the symbols for k and l might be a way to avoid these.

PeteSteinfeld requested review of this revision.May 12 2020, 3:19 PM
PeteSteinfeld marked 5 inline comments as done.
PeteSteinfeld added inline comments.
flang/lib/Semantics/check-declarations.cpp
157

Oops. I'll remove this.

287

No reason. I'll combine them.

flang/lib/Semantics/resolve-names.cpp
3916

Thanks, Peter. It looks like I can move it, and I will.

3922

No longer necessary in the moved code.

flang/test/Semantics/resolve33.f90
42

Constraint C754 states that a type-param-value in a component-def-stmt shall not depend on the value of a variable. In this case, the type-param-value of "len" depends on "l" (lower case ell), which is a variable. But the message incorrectly says that the expression is associated with a derived type component.

Note that the constraints on specification expressions in derived types are identical for bounds expressions of components and for values of type parameters. Do you think it's important that the error messages distinguish these two cases?

tskeith added inline comments.May 12 2020, 4:16 PM
flang/test/Semantics/resolve33.f90
42

l isn't a variable, it's a type parameter that's missing its definition (which we've already complained about).

PeteSteinfeld marked an inline comment as done.May 14 2020, 12:18 PM
PeteSteinfeld added inline comments.
flang/test/Semantics/resolve33.f90
42

My understanding is that a type parameter is a variable. The relevant sections of the standard that I could find are 5.4.3.2.2 that defines variables, and 5.4.3.2.1(3) that states that a subobject of a variable is a variable.

I like your suggestion of stopping analysis of expressions containing names that have already been found to be erroneous. In this example, the compiler is not creating a Symbol for the type parameter l. I think that the right thing to do is create a Symbol for l at the point where the compiler emits the error message, and then mark the newly created Symbol as erroneous. Then, subsequent semantic processing will know not to emit redundant and possibly confusing messages when encountering it.

  1. Updating D79798: [flang] Constraint checks C751 to C760 #
  2. Enter a brief description of the changes included in this update.
  3. The first line is used as subject, next lines as comment. #
  4. If you intended to create a new revision, use:
  5. $ arc diff --create

Responses to review comments

I changed the error messages to specify that errors in specification
expressions could arise from either bad derived type components or type
parameters.

I moved error detection for constraint C756 from resolve-names.cpp to
check-declarations.cpp.

I collapsed a nested if statement to a single if with a more complex
condition.

In cases where we detect a type param that was not declared, I created a symbol
marked as erroneous. That avoids subsequent semantic process for expressions
containing the symbol. This change caused me to adjust tests resolve33.f90 and
resolve34.f90. Also, I avoided putting out error messages for erroneous type
param symbols in OkToAddComponent() in resolve-names.cpp and in
EvaluateParameters(), type.cpp.

@klausler and @tskeith, do these latest changes look good?

tskeith added inline comments.May 15 2020, 1:27 PM
flang/lib/Semantics/resolve-names.cpp
3677

You can use BeginAttrs here instead, and EndAttrs below.

flang/lib/Semantics/type.cpp
156

Could be else if

PeteSteinfeld marked 2 inline comments as done.

I changed some raw code to calls to BeginAttrs() and EndAttrs() and changed a
nested "if" to an "end if".

I've submitted another update.

flang/lib/Semantics/resolve-names.cpp
3677

Thanks, Tim. Will do.

flang/lib/Semantics/type.cpp
156

I will make it so.

tskeith accepted this revision.May 15 2020, 2:20 PM
PeteSteinfeld accepted this revision.May 15 2020, 7:14 PM

Changes have been delivered.

This revision was not accepted when it landed; it landed in state Needs Review.May 15 2020, 7:33 PM
This revision was automatically updated to reflect the committed changes.