Flang admits non-polymorphic instances of abstract derived types as procedure arguments

[difference-scheme]

This is related to Issue #873. This, too, is invalid code that should be rejected by the compiler.

program test

   type, abstract :: basic
   end type basic

contains

   subroutine tester(obj)
      type(basic), intent(in) :: obj
   end subroutine tester

end program test

[kiranchandramohan]

f18 also does not seem to catch this.

[difference-scheme]

@kiranchandramohan Feel free to include these samples into both the flang/f18 test suites.

[tskeith]

I get this from f18:

t.f90:9:7: error: ABSTRACT derived type may not be used here
        type(basic), intent(in) :: obj
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[kiranchandramohan]

Apologies. Thanks for the update @tskeith.
Yes f18 does catch it. I was using an old build.

[difference-scheme]

Given that f18 has been targeting Fortran 2018 from its inception, can we expect Fortran's object-oriented features to be in better shape in f18 than in contemporary compilers (once f18 produces code)?

[kiranchandramohan]

@difference-scheme I can make only a general statement here. f18 has been designed on a horizontal basis using Fortran 2018 as a reference. This means that care has been taken to represent all constructs in the standard in each stage. Parsing for Fortran 2018 is complete. Semantic Checks are nearing completion. High Level IR is maturing and making its way into the master branch. The High Level IR (FIR) has explicit representation for dispatch tables which helps with dynamic dispatch (an object-oriented feature). (https://github.com/schweitzpgi/f18/blob/a8a4cf36b59d7442eecd03feca285faad080f445/documentation/FIRLangRef.md#firdispatch)
So I expect it to be in good shape.

[mleair]

Just an FYI: This bug occurs only with empty abstract derived types. If the abstract type is non-empty, Flang issues an error. For example,

program test

type, abstract :: basic
integer :: i
end type basic

contains

subroutine tester(obj)
type(basic), intent(in) :: obj
end subroutine tester

end program test
% flang abs.f90
F90-S-0155-illegal use of abstract type basic (abs.f90: 10)

[difference-scheme]

@mleair Thanks for pointing this out.

[difference-scheme]

@kiranchandramohan Thanks for your assessment and the link you provided. This sounds great! I am looking forward to using f18, once it lands in llvm.

[kiranchandramohan]

@difference-scheme Just to clarify, I am not saying that there will be full support of object-oriented features when f18 lands in LLVM. It will take some time to get there but the design has considered these features from the ground up. Also, work is ongoing to i) implement and move FIR from a branch to master and ii) runtime.

[difference-scheme]

@kiranchandramohan I see. Unfortunately, and even if they would be supported as soon as f18 lands in LLVM, Fortran 2018's OO features are sorely lacking. Here is a PR of a proposal to J3 for rectifying this in future standards: j3-fortran/fortran_proposals#143

Would any of the developers here be interested in prototyping such new functionality in f18? I've tried to familiarize myself with the f18 code-base but, unfortunately, I found it very hard to do so.

[kiranchandramohan]

I cannot speak for everyone but given that the development of F18 is in progress, I believe the preference would be to get F18 into a fully functional state. Also, to fully prototype this feature I believe F18 should have FIR/MLIR code generation. So I guess this has to wait for some time.
It is desired that F18 becomes a platform for prototyping new features for standardisation. Does the feature that you require additional syntax. If so, parsing it in, representing in parse tree and unparsing it back to Fortran should be the first step. Did you try that? What difficulty did you face?

[difference-scheme]

@kiranchandramohan Thanks for your reply and your suggestions. Your plan for f18 development sounds perfectly reasonable. The features I have in mind do require new syntax.

I have tried to understand the f18 parser code, but I couldn't figure out the basic data structures that it relies on. There is some heavy macro usage, and templating going on in the code, along with some C++17 magic that made me conclude that I don't have the necessary background to try and dig any deeper.