Re: semantic-analyze-possible-completion

Eric Ludlam <[email protected]> Sat, 31 Jan 2015 09:39:50 -0500
Newsgroups gmane.emacs.cedet
Message-ID <[email protected]>
On 01/30/2015 08:30 AM, Martin Stein wrote:
> Hi Fulvio, Eric,
>
> I read up on namespaces and ran a small C code with namespace through the bovinator to check the tag structure. From all I can see namespaces fit the module concept pretty well, indeed. As I can see from the tag tree, tags of class 'type are used for almost everything :) It gets really confusing, when putting all those "type" together:
> namespace: ("foo" 'type :type "namespace")
> using:     ("std" 'using (:type ("std" type (:prototype t :type "namespace"))))
> struct:    ("bar" 'type :type "struct") (same with class)
>
> and for Fortran this woulde become
> module:    ("mod" 'type: type "module)
> type:      ("bar" 'type :type "type")
> That last line looks like one beer too many :)

If a module or type is of class 'type, it will get collected into the 
typecache.  The only type that is special in the typecache is 
"namespace".  Namespaces whose names are the same will have their 
contents merged.  This is because code like this:

namespace foo { int sym1; };
namespace foo { int sym2; };

keeps adding symbols to the foo namespace.

If modules behave like this, we'll need to take action in the typecache 
to allow languages to specify which types of types get symbols merged.

> I guess with that information I can get going again. Just two more question:
> (1) There does not seem to be a concept of public/private for namespaces, in contrast to modules within fortran. Are there any problems to be expected for the context analysis? If it dives into a tag of class 'type and :type of "module" it will find members which are private and should not be exported. Even so namespaces does not seem to have such a feature, other types such as class know about that, so this should work for fortran modules, types etc. as well.

Protection for tags varies pretty widely, so to specify custom behavior 
you need to override `semantic-tag-protection'.

This is checked whenever tags are extracted from some type, typically a 
"class" or "struct".  For C++, it also overrides 
`semantic-find-tags-by-scope-protection' which is how the scope system 
pulls out only the available tags.  It may apply to namespaces in the 
scope code.  I don't recall the specifics.

> (2) In C there are just functions, and somehow the 'function class has some special meaning. Introducing 'subroutine and 'program tags might not be a good idea?? If it might be a problem for semantic default routines, it might be a good idea to store subroutine tags as 'functions of some special :type "subroutine"? Same with program (which is the equivalent of main in C).

The generic tag classes such as function and type are meant to describe 
the nature of a tag in a generic way.  In languages that are not 
functional (like Makefiles) the tag class can be very different.  If 
programs and subroutines are just like functions (call them by name) 
then they should have a class of function to maximize how much of the 
existing semantic infrastructure will work with them.  Since they are 
different in a fortran sense, you will want to invent an attribute so 
you can differentiate.  For example, the tag formatters may choose to do 
something different.  You might have a :fortran attribute that you use 
in your tags to provide the right differentiation.

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/