PR 15211: How does gfc_conv_intrinsic_len work?

[Paul Brook]

> Now the testcase passes, some contrived examples I made up work, the
> testsuite passes with no new regressions, but I have little idea why
> this works. Maybe explaining the comment questioning the user's
> intelligence would help me understand what is going on here. If it's
> stupid because the user always knows the length of a string in a user
> defined type, then my patch seems right, but I can't tell for sure.
>
> So, is this right? If it is, please assign this PR to me. I will prepare
> a patch + an updated testcase, and submit once my copyright assignment
> is in place.

Your changes look wrong.

The idea behind the code was:
(a) If we have something reasonably simple (a variable reference), extract the 
string length expression directly from the decl. This needs extending to 
handle component and array references.
(b) Otherwise (to handle arbitrary expressions) we feed it through the normal 
expression translators, and ignore most of the result. This is curently 
broken for array valued expressions.

Examples of things we should be able to handle:

  interface
    pure integer function bar(a)
      integer, intent(in) :: a
    end function
    function foo(i)
      integer :: i
      character (len=bar(i))) :: foo
    end function
  end interface
  character(len=10) :: c, d
  character(len=6), pointer :: e(:)

  print *, len(foo(42))
  print *, len(trim(c))
  print *, len (a//b)
  nullify(e)
  print *, len (e)

Paul