<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/63775>63775</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [flang][polymorphic] Type descriptors are not emitted during separate compilation
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          rofirrim
      </td>
    </tr>
</table>

<pre>
    I'm aware the polymorphic support is still experimental but I think it is useful to have this recorded.

Consider the two following files:

```fortran
! mymod.f90
module mymod
 implicit none
  type, abstract :: myfoo
    integer :: x
  end type myfoo
end module mymod
```
```fortran
! mymod2.f90
module mymod2
  use mymod, only: myfoo
  implicit none
  contains
 subroutine mysub(myparam)
      implicit none
      class(myfoo), pointer :: myparam

      nullify(myparam)
    end subroutine mysub
end module mymod2
```

If we compile them separatedly, `mymod2.f90` will crash while generating FIR because the type descriptor of `myfoo` has not been emitted and `nullify` needs it.

```
$ flang-new -flang-experimental-polymorphism -c mymod.f90
$ flang-new -flang-experimental-polymorphism -c mymod2.f90
error: loc("/home/rferrer/fio/upstream/llvm-install/tmp/mymod2.f90":11:7): no type descriptor found for NULLIFY
LLVM ERROR: aborting
```

I looked into it a bit and IIUC, it seems that the type descriptor is emitted as part of `lowerModuleDeclScope` in the Bridge. If the two files together are compiled as a single file (e.g. adding an `include 'mymod.f90'` at the beginning of `mymod2.f90`) then the crash does not happen because the descriptor is indeed emitted.

In a separate compilation setting, AFAICT the module is loaded and parsed and its names resolved but I don't think we synthesise enough information so the type descriptors get emitted as a consequence of a `use`-statement. One thing I saw is that the descriptors (and other runtime info) are already emitted as weak global objects so emitting repeated definitions in different object files should not be a problem.

Any hints on how we could address this? I wonder if it makes sense to check use-associations to derived types and emit their descriptors if they haven't been emitted yet?
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJycVl1v2zoS_TX0yyCGTPkjfvCDm6wAA-kWyLYL7CMljiRuKI4uSdXVv78YSq6dxr24uEEgyNRwvs6ZQ6oQTOMQD2LzSWyeF2qILfmDp9p4b7pFSXo8nITcdaDOyiPEFqEnO3bk-9ZUEIa-Jx_BBAjRWAv4o0dvOnRRWSiHCCeIrXFvYJLRELAeLESCVn1ndyaAx4q8Rr0U2bPIjtPziVwwGn2KGM8ENVlLZ-MaqI3FIPLjrbnYZtN_TT565eZVuYJu7Egv6302LXWkB4vT6rQCpuutqUwERw7nNYhjj0I-gSpD9KqKwAHzI3RjTXQxAjAuYoP-8vXH5Qs6nVzc2vPax_A_M_9bhcj7lchL3CFcnMsnIGfHDznfrbYiF5VxYf4dhtLTEI1jZ2EohXzsxl551Qm5vxb_G2f8V1kVQtrGoeWe0-mJu-WvnZw83qA47XWDtaYefxOUu_ghv7v9lfcbnJ6nGs4IFXW9sYnVHQTkYBG1HTlbsc1uOr7N4Mz0rrwKLZxb3tWgQ68iU7I4vUKJleL2J8Iy9BpD5U0fyQPVkz9uxjaDVgVwFKFEdICdiRE1KKfZ6FL9NgOHqAOYuLzL9Asz1lBb5ZoHh2d4mF5vh_DhOq6hg4fq14H4hw5uiIjek2dELVVCPgophSxa6lDIwtfoPXohi9qQkMXQh-iRIS2s_d49GBeislbIIna9kMWNbylFflytRH7cMQHyIzj60NiaBqehJg___vbycir-N6X08vLfz_Cv19cvr7xPleQZpr_iA1iiN9Q80MRapaDkp9NwOn17YkKYCAGxCxBbFe-ibMIVzAC98nEG3tIZ_edEzWes7H8q6pEBNi75-eSNbnAJp_qqdqxxEKnB2KIHlt6ZrMm3gmBcYzHZgZCPuGyWoLRmMirHMY2r7KD54-6KuNxx2Dn9EhvjHO-40POG7kLu2WhKcGK9Jpxo26q-R_eO8O-7YJxG1JdmvKPvyXHy86jNNaloyEHAmECST3Asjqenr8nxPNAmgCWl5zHplQ_zq4kBnOqQj5FA9jvq-dTR5ITcxfn0OSOE0cUWgwkI6GhoWjCuJt_N0ekepAEajLegKpbKgH8M6Crkvinu3BAYzocQVUQemiV8celwcw2cIKgz5_-TNrfuhXzkKiih7AcXTYcpL-4_o66sR6XH2xzOqN6gsVQqC1T-H6sYOP1kwRE99sg6Bhpr4wyXx5CANnWNHl2cd80kCy0NVs96BAp6T6XF7h1qRzdCa1wMQA5aOk_iyduU1h5DSCe5yAs4wZkcn9um5onp1BuHQMc8IaharN74kHpQIVBl1JRcJNDoDYPHAISELNfD_TL-XcdMGpIx3R8mhN-p6IhR5MVCH3K9z_dqgYfV9vFxv1tvHvNFe9jlVZmt13us8lKuUOp6s6kztV2ts_Vqm5ULc5CZzLPdKst2-Vbmy9Ver_ZbXNXbGrdruRbrDDtl7JL1a0m-WZgQBjxs891us7CqRBvSdUpKFtT0kbVs87zwh6R55dAEsc6sCTFcvUQTbbqHJQUWm2ex-XRz0xKbZ_j6KzmZIIzbpXg9eCbAvfFaDN4e2hj7dHOShZBFY2I7lMuKLmp8EeXeE_NDyCJlH4QsUnV_BgAA__9rMFrg">