[PATCH] D79798: [flang] Constraint checks C751 to C760

[Pete Steinfeld via Phabricator via llvm-commits]

PeteSteinfeld marked an inline comment as done.
PeteSteinfeld added inline comments.


================
Comment at: flang/test/Semantics/resolve33.f90:43
     !ERROR: Must be a constant value
+    !ERROR: Invalid specification expression: derived type component not allowed to reference variable 'l'
     character(kind=k, len=l) :: d3
----------------
tskeith wrote:
> PeteSteinfeld wrote:
> > tskeith wrote:
> > > klausler wrote:
> > > > This error seems spurious to me.  We know that `l` (lower-case letter ell) is a type parameter.
> > > 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.
> > 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?
> `l` isn't a variable, it's a type parameter that's missing its definition (which we've already complained about).
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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79798