Re: semantic-analyze-possible-completion

Hello Martin,
it seems to me from a superficial glance at code in c.el that the magic is
contained inside the following piece of code:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
;; This searches a type in a namespace, following through all using
;; statements.
(defun semantic-c-check-type-namespace-using (type namespace)
   "Check if TYPE is accessible in NAMESPACE through a using statement.
Returns the original type from the namespace where it is defined,
or nil if it cannot be found."
   (let (usings result usingname usingtype unqualifiedname members 
shortname tmp)
     ;; Get all using statements from NAMESPACE.
     (when (and (setq usings (semantic-tag-get-attribute namespace 
:members))
                (setq usings (semantic-find-tags-by-class 'using usings)))
       ;; Get unqualified typename.
       (when (listp (setq unqualifiedname (semantic-analyze-split-name
                                           (semantic-tag-name type))))
         (setq unqualifiedname (car (last unqualifiedname))))
...
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 From which it appears to me that each namespace can have some members 
of class 'using,
each representing a namespace clause, this is parsed to get the 
namespace name and the
symbols found there. It also makes the search recursively, which exactly 
maps to the fortran
semantic for use clauses.

Fulvio

On 30/01/2015 11:49, Martin Stein wrote:
> Hi Eric, Fulvio,
>
> thanks for the advice and help to both of you. I have renamed 'module to 'type and 'type to 'derivedtype to check out Eric's assessment, and it at least got me a better context than before. However, from a language point of view this just feels very wrong. I want to get this right without wandering down the wrong road, so I hope I will not pester you with questions too much.
> To give a more complete Fortan example involving derived types (defined as well as declared by the type keyword, which is a synonym to both struct as well as class in c++)
> (fortran comments are started with !):
>
> ### example starts here
>
> module mod
>
> ! use is a bit like an include in C++ (and currently represented by an include tag)
> use some_module
>
> ! something like a list
> type mytype
>    integer :: a
>    type(mytype), pointer :: next
>    contains
>      ! that Fortran 2003, not yet supported by me, but should be kept in mind
>      procedure :: get_key => my_get_key
> end mytype
>
> public mytype, sub
>
> contains
>
> ! just some subroutines, which are like C functions of type void
> ! the subroutine can always be accessed by all module members,
> ! and in this case also by whoever imports the module mod (because of the public statement above)
>    subroutine sub(l)
>      use some_special_module
>      type(mytype), intent(inout) :: l
>    ...  code ...
>    contains
>       ! functions and subroutines in this contains part are only seen by subroutine sub
>       function a_helper(arg)
>       ...
>       end function a_helper
>    end subroutine sub
>
> ! the result keyword binds a local variable to the function return value
>    function my_get_key(l) result(a)
>       type(mytype), intent(in) :: l
>       integer :: a
> ! the % symbol is like the -> arrow in c++
>       a = l%a
>    end function my_get_key
>
> end module
>
> ### example ends here
>
> The current ttag structure is something like top-level = ((some include tag) ("mod" 'module :members members :public ...))
> with members = ((tag for mytype definition) ("sub" 'subroutine :members (tags of local vars, a_helper, ...)) ("my_get_key" 'function :type "integer" :result a :members ...)).
>
> As you can see (and from what I know of C/C++), nesting of scopes is more complicated in Fortran than in C, so I think that fooling semantic by using class 'type for modules might not really solve the problem (as there are still those types called derived types in fortan lingo) and be a hindrance in the long run.
> I am not familiar with C++ namespaces, so I will check that out next, thanks Fulvio for pointing that out.
>
> BTW: I have forked cedet for having an easy backup of ideas and codes of my fortran efforts. If anyone wants to check that out or even contribute code or grammar I can give read or readwrite access to it. At the moment the parser understands quite a bit of F90/95 and produces detailed tags on anything not being code.
>
> Martin
>
>
>
>> Gesendet: Freitag, 30. Januar 2015 um 09:16 Uhr
>> Von: "fulvio ciriaco" <[email protected]>
>> An: "Eric Ludlam" <[email protected]>, "Martin Stein" <[email protected]>, [email protected]
>> Betreff: Re: [CEDET-devel] semantic-analyze-possible-completion
>>
>> Hello,
>> perhaps Eric could give further advice knowing that the
>> fortran <use modulename> clause maps perfectly to the c++
>> <using namespace modulename> clause.
>> The module could be in a similarly named file but also elsewhere
>> and a file can indeed contain several modules.
>> So, one could say that a fortran module and a c++ namespace
>> are actually the same concept.
>>
>> Fulvio
>>
>> On 30/01/2015 04:13, Eric Ludlam wrote:
>>> On 01/28/2015 05:30 PM, Martin Stein wrote:
>>>> Hi,
>>>>
>>>> I got somehow lost trying to figure out how to get completion to work
>>>> with my fortran parser.
>>> Anything past completing some top level tag names gets tricky the
>>> farther you diverge from how C++ represents tags in Semantic.
>>>
>>>> A typical example looks like:
>>>>
>>>> module mod
>>>>
>>>> use some_module
>>>>
>>>> contains
>>>>
>>>>       subroutine sub(arg)
>>>>       ...
>>>>       end subroutine
>>>>
>>>> ...
>>>>
>>>> end module
>>>>
>>>>
>>>> Accordingly there is one big tag of class 'module, containing in its
>>>> attributes all the information, in particular there is a 'subroutine tag
>>>> of name "sub" buried in :members. Now if I type "call s" I expect that
>>>> sub is found, but it is not.
>>> You are using terms like 'module and 'subroutine.  Does that mean the
>>> class of your generated tags are 'module and 'subroutine?  Looking in
>>> the old f90.by parser, I see it is creating tags without using TYPE-TAG,
>>> FUNCTION-TAG, etc macros.
>>>
>>> If a 'module' acts like a 'type' (ie - a class or struct in C++) then it
>>> should use that tag class instead of 'module'.  Likewise for subroutine.
>>>
>>> You can use semantic-symbol->name-assoc-list to give them more fortranny
>>> type names for humans to read.
>>>
>>>> If I want to have a function name completed in C code, relevant
>>>> functions are found as top level tags (as there is no encompassing
>>>> module-like structure), hence (semantic-analyze-find-tags-by-prefix
>>>> completetext) in line 192 of analyze/complete.el finds the proper tag.
>>>>
>>>> I know that semantic-analyze-possible-completions does the work and is
>>>> overloadable. Should I overload this function? It seems that the code
>>> Hopefully not.  Overloading right at the possible completions function
>>> is for languages where the usual analysis is unneeded, and when there is
>>> some better way to do it.   For example, in grammar mode, it overloads
>>> so it can figure out if it is completing in lisp code, or in grammar
>>> code, then forks off to the right completion engine.
>>>
>>>> structure outlined above does not fit its inner workings, which is
>>>> designed for C. On the other hand this function is overloaded only for
>>>> some corner-cases (clang, part of grammar).
>>>> Do I miss something and that routine should still work for fortran, e.g.
>>>> by overloading some buried helper functions? For example, the relevant
>>>> tags are contained in the context object. But it does not seem to be
>>>> queried for those tags? (At least not in my small C example I tested).
>>> Right.  Usually all that is needed is to implement a few key functions,
>>> like where to find include files, how to extract tag members, and the
>>> like.  I don't know enough fortran to know where the problem is, though
>>> I suspect you can mash some fortran concepts into vaguely similar c
>>> constructs to make it work as I mentioned above.  Java completions
>>> worked with very little modification due to the similarities.
>>>
>>> My first step in debugging this stuff is to get each of the fields in
>>> the context returned by `semantic-analyze-current-context' to work.
>>> Once there is a context, the completion engine extracts the found tags
>>> (in the :prefix) to calculate the completions.  For example, for this C
>>> code:
>>>
>>> struct foo {
>>>      int bar;
>>> };
>>>
>>> int myfunc() {
>>>
>>>      struct foo me;
>>>
>>>      me.b -!-
>>>
>>> }
>>>
>>> the analyzer returns:
>>>
>>> Prefix: struct foo me
>>>            "b"
>>>
>>> meaning it found "me" and turned it into a tag, but doesn't know what
>>> "b" is.
>>>
>>> So it looks at the datatype of "me", calls
>>> `semantic-analyze-scoped-type-parts', which is a fancy variant of
>>> `semantic-tag-components' which you may need to override.
>>>
>>> from that list it looks for things that start with "b".
>>>
>>> If the prefix were just "b", then it would look that up just using basic
>>> tag searching routines across global tables.
>>>
>>>> Another question:
>>>> What do I need to do to include tags from other modules (included via
>>>> "use some_module" as in the example above)? I could not find
>>>> documentation (or hints in other language files) for that.
>>> You probably need to override semantic-find-tags-included (there are
>>> some examples in c.el) and to make sure your `use' tags show up as
>>> `include' tags.  You probably also need to override
>>> `semantic-tag-include-filename' to convert the used symbol name
>>> "some_module" into a file name "some_module.f90".
>>>
>>> There was another question where a statement was doing double-duty as an
>>> include and as a 'use' statement.  I only have a guess for that at this
>>> time regarding expanding it into two tags.  There is probably a better
>>> idea though.
>>>
>>> Eric
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>>> look and join the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Cedet-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>>


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/