GNOME Bugzilla – Bug 701893
Fortran 2003+ inheritance
Last modified: 2018-07-30 10:07:19 UTC
Created attachment 246349 [details] Sample test case (one module, the main program and the Doxyfile used) Current Doxygen is not able to parse Fortran 2003+ extensible types and the associated inheritance relations due to two compounded bugs: 1. Name searching for base types seems to be case-sensitive (see Child1 vs. Child2 in mod.f90), causing the parent type to be shown as unknown in the generated documentation; that is, with only the name and no link to the actual base class. The expected behaviour is that declaring a type as extends(AnotherBase) should work and be recognized in the documentation inheritance list because Fortran is case insensitive. 2. Name searching for base types does not work for bases in other modules (see the types in main.f90), causing the parent type to be shown as unknown as before. The expected behaviour is that name resolution should be performed on the PUBLIC symbols of all USEd modules in addition to the symbols in the current scope. Conceptually, "USE module" would be similar to a Java "import module.*;" A workaround exists for both bugs, as Doxygen allows manually specifying "@extends anotherbase" in the first case or "@extends mod::base_type" in the second. However, this is clumsy and produces ugly documentation, since Doxygen understands that an _additional_ base class is being specified and shows the child type as using multiple inheritance, with both the unknown and the manually-specified bases.
An update: cross-module name resolution works for specifically-imported names, that is, for classes imported with "USE mod, ONLY : class_name". This is only a workaround for problem 2, however, and does not solve problem 1 because the matching seems to be case-sensitive.
Created attachment 246353 [details] [review] Apply lower() on certain statements This proposed patch applies lower() to the detected names in the following directives (only in the scanner, I haven't touched the code pretty-printer): - USE m - USE m, ONLY : x - TYPE t - EXTENDS(u) This appears to fix the problem 1 mentioned above. However, I'm not quite happy about the way Doxygen seems to handle case-insensitive languages: the generated documentation with all names in low-caps is quite ugly and unreadable, particularly if camelCaseNaming is used instead of using_underscores. It remains to be seen if there are other places where fortranscanner.l fails to use .lower() where it should. My take for that is the following: I think that in non-case-sensitive languages, Doxygen should store the "declared name" of an entity, using it only for rendering purposes (MyTypeName, myFunction); while its "effective name" (with a standard case for comparisons) is used for all other purposes, as it is right now.
As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to https://github.com/doxygen/doxygen/issues All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github. Hence I am closing this GNOME Bugzilla ticket. Please use the corresponding ticket in Github instead. Thanks a lot!