Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse Fortran 2003 enum #406

Merged
merged 2 commits into from
Jul 31, 2015
Merged

Conversation

QingmingHe
Copy link
Contributor

Fortran 2003 enums is:

enum, bind(c)
  enumerator [::] name1 [= val], ...
end enum

See https://books.google.com.hk/books?id=40UkLNQuAeoC&pg=PA114&lpg=PA114&dq=fortran+enumerator+type&source=bl&ots=WTou0LNC5z&sig=kV-2jyz4T2qUlCQ3T4jx3WeRJkc&hl=zh-CN&sa=X&ei=JZeSVbSSH5DYoAShrI6gDA&ved=0CEcQ6AEwBTgK#v=onepage&q=fortran%20enumerator%20type&f=false page 114
and http://www-01.ibm.com/support/knowledgecenter/SSGH4D_10.1.0/com.ibm.xlf101a.doc/xlflr/enum.htm%23enum

We shoud note that

  • bind(c) is mandatory
  • enum shoud have no name
  • enumerator should have no qualifier

The implementation of Geany is different geany/geany@9520e7f which is based on
http://docs.cray.com/books/S-3692-51/html-S-3692-51/z970507905n9123.html. The syntax is different:

  • kind selector can be used instead of bind(c)
  • enum can be given a name

The docs of ISO http://www.j3-fortran.org/doc/year/04/04-007.pdf page 66 don't allow for syntax of cray.

@QingmingHe
Copy link
Contributor Author

The question is whether we should support compiler specific features or not.

@QingmingHe
Copy link
Contributor Author

As the original implementation is just a subset of that of Geany, I fully import that of Geany.

I'm not quite sure whether kind selector and enum name are standard Fortran 2003 syntax. But at least they are allowed by Cray compiler and discussed here http://www.j3-fortran.org/doc/year/00/00-121.pdf.

@masatake
Copy link
Member

masatake commented Jul 4, 2015

Do you mean there are two fortran syntax(fortran2003 and cray) for enum definition?
Is it impossible to accept both syntax in ctags? Is there serious confliction?

I'm not sure I can give you a constructive comment I would like to see a typical problematic fortran causing the confliction. In addtion I would like to see tags output generated by ctags following fortran 2003 syntax and by ctags following cray syntax.

Surprisingly, createTagsForFile allows a parser doing multiple path parsing. If parising by a syntax is failed, paring by another syntax can be run. If we cannot find any good solution, you can use this feature.

@QingmingHe
Copy link
Contributor Author

Sorry for replying late. I moved both dormitory and researching room in last week, having no access to Internet, feeling being dropped by the world...

Do you mean there are two fortran syntax(fortran2003 and cray) for enum definition?

Not two syntax, Cray compiler has its own extension to standard Fortran 2003. Besides, the extension syntax is discussed to be incorporated in to standard syntax.

Is it impossible to accept both syntax in ctags? Is there serious confliction?

As I mentioned, standard Fortran 2003 is a subset of Cray. So if ctags support Cray, it will also support standard F2003. There should be no confliction.

As the the trashbox will be removed in #425, I will modify this patch after merging #425.

@masatake
Copy link
Member

The commits of #425 is merged.

Allow for not-yet-standard enum naming using `:: name` syntax, see
http://docs.cray.com/books/S-3692-51/html-S-3692-51/z970507905n9123.html

Authored by Colomban Wendling <ban@herbesfolles.org>

The difference from that of Geany is that the kind of enumerator is 'N'
rather than 'F'. This is because KIND_FILE_DEFAULT is 'F' defined in
parse.h. If kind of enumerator is 'F' then doesParserUseKind will return
TRUE which will make an assertion.
Test cases contributed by Adam Hirst
QingmingHe added a commit that referenced this pull request Jul 31, 2015
@QingmingHe QingmingHe merged commit d8f12a6 into universal-ctags:master Jul 31, 2015
@QingmingHe QingmingHe deleted the fortran-enum branch July 31, 2015 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants