ABSTRACT interfaces + PROCEDURE declarations

[Tobias Burnus]

Hi Janus,

some remarks without looking at your patch (I will review it later).


Janus Weil wrote:
> One thing that I'm working on right now is to implement some checking
> if the FUNCTION implementation actually matches the PROCEDURE
> declaration. I've already added some code in decl.c
>   
As you wrote yourself, the checking in decl.c comes too early. You need
to put the checking into resolve.c. (I have not yet thought about where
in resolve.c.) Keep in mind that there are also intrinsic functions,
some of which can take arguments of different kinds (though not all are
allowed, cf. C1212/R1215) -- and remember also that implicit interfaces
are also possible: "PROCEDURE(REAL) ::PSI" to quote the Fortran 2003
standard.


Other notes:

- Use :ADDPATCH fortran: if you submit a patch; it then ends up at
http://dberlin.org/patches and won't be forgotten; see also
http://dberlin.org/patchdirections.html
That way it will not be forgotten - and if you send a fix for a certain
bug report (PRxxxxx), it will automatically add a link to the patch in
bugzilla. Using ADDPATCH is not that important - if no one reviews, you
have simply to *ping*.

- For patches you also need to CC gcc-patches@gcc.gnu.org - this allows
non-Fortraners to comment on your code (esp. useful for changes in
trans*.c).

- You need to write a changelog (or actually up to three changelogs, one
for: libgfortran, one for gcc/fortran and one for gcc/testsuite), syntax
as follows.

Note the two spaces between date/name and name/email.
Note that the following lines are preceeded by a tab.

Example:

2007-08-15  Janus Weil  <jaydub66@googlemail.com>

	* interface.c (gfc_match_interface,gfc_match_abstract_interface,
	gfc_match_end_interface): Add abstract interface.
	* decl.c (access_attr_decl): Ditto.
	* gfortran.h (interface_type,symbol_attribute): Ditto.
	* module.c (gfc_match_use,ab_attribute,attr_bits,
	mio_symbol_attribute): Ditto.
	* resolve.c (resolve_function): Ditto.


etc. If you find a better description than "Ditto." you are free to use
it. Have a look at the ChangeLog files for good/not-so-good real-world
examples.


Without looking at dump-parse-tree.c in detail: Does one need to handle
abstract interfaces there? Or is the output already ok?

Secondly, you should add test cases (to be put at
gcc/testsuite/gfortran.dg/*), consisting of run-time tests (make sure
that the feature works) and compile time tests (make sure that errors
are correctly found). Writing test cases also helps to find bugs. Syntax
in a nutshell:
! { dg-do compile }
or
! { dg-do run }
(spaces before/after { and } are needed)

In the line where an error/warning message is to be expected:
! { dg-error "error message" }
! { dg-error "warning message to match" }

And if you have modules, which compile correctly:
! { dg-final { cleanup-modules "name_of_mod_file_w/o_.mod" } }
to remove the .mod files.

You also need to run "make check-gfortran" in $GCCBUILD/gcc to make sure
your test cases work and you did not break anything.

Tobias