Re: Typecache does not contain include tags created at expansion

OK, I think I got it : I did not override `semantic-find-tags-included' for
php-mode, and this was required to find include tags defined inside a
namespace. When "semantic/bovine/c" is loaded, it overrides
`semantic-find-tags-included' for c-mode. As php-mode derives from c-mode
this solves the issue.

Now, I wonder what is the cleanest way to solve the issue: I can define
`semantic-find-tags-included' in php-mode, and that will avoid a dependency
to "semantic/bovine/c". However, the code will be exactly the same, so this
leads to duplication. On the other hand, I can still load
"semantic/bovine/c" to share code and avoid duplication, but this leads to
one more dependency.

In my opinion sharing code is not a bad idea, so I would rather include
"semantic/bovine/c" in "contrib/wisent-php". What do you think about it ?

2015-01-21 23:01 GMT+01:00 Steven Rémot <[email protected]>:

> Just a little update: I could make semantic load the include tags by
> including semantic/bovine/c package in contrib/wisent-php. I will try to
> understand why it works when I load C support, in order to make wisent-php
> work by itself.
>
> 2015-01-04 15:25 GMT+01:00 Steven Rémot <[email protected]>:
>
>>  Le 03/01/2015 21:20, Eric Ludlam a écrit :
>>
>> Using the 'dump' feature should force the include stream to be filled, so
>> there is some other reason why it is empty.  Since 'dependents' has an
>> entry, I'll assume that is your include tag.   It is possible that since
>> you are developing your grammar as you go, some buffers are in different
>> parsing states.  I recently patched CEDET in bzr (and now git) back in..
>> November? to better update buffers when you compile your grammar.
>>
>> Thanks for your answer Eric. The entry in dependents is a scope cache
>> containing the include tag and other thing. Here is the result of the
>> typecache dump a bit more unfolded :
>>
>> ]#<semanticdb-typecache /<project
>> dir>/src/AnotherNs/SuperGreeterCaller.php>
>>    ] Name: "/<project dir>/src/AnotherNs/SuperGreeterCaller.php"
>>    ] Class: #'semanticdb-typecache
>>    ] filestream #<TAG LIST: 1 entries>
>>      * AnotherNs : namespace
>>    ] includestream : nil
>>    ] stream : nil
>>    ] dependants #<list o' stuff: 1 entries>
>>      > #<semantic-scope-cache Cache>
>>          ] Name: "Cache"
>>          ] Class: #'semantic-scope-cache
>>          ] :table #<semanticdb-table SuperGreeterCaller.php (1 tags)>
>>          ] tag +callSuperGreeter
>>          ] scopetypes : nil
>>          ] parents #<TAG LIST: 2 entries>
>>          ] parentinheritance : nil
>>          ] scope #<TAG LIST: 4 entries>
>>          ] fullscope #<TAG LIST: 6 entries>
>>            * +callSuperGreeter
>>            * SuperGreeterCaller : class
>>            * /<project dir>/src/NewNs/SuperGreeter.php
>>            * Greeter : use
>>            * AnotherNs : namespace
>>            * SuperGreeterCaller : class
>>          ] localargs #<TAG LIST: 1 entries>
>>          ] localvar #<TAG LIST: 4 entries>
>>          ] typescope : nil
>>
>> If you need it, you can reproduce my problem by installing php-mode (easy
>> through MELPA), and then use these commands to checkout my code and run my
>> ERT tests with "emacs -q" :
>>
>> git clone https://bitbucket.org/stevenremot/cedet
>> cd cedet
>> git checkout php-tests
>> make
>> cd contrib
>> make
>> cd tests/php
>> sh run-test.sh
>>
>>   2 tests should fail, "wisent-php-argument-completion-through-alias",
>> and "wisent-php-in-depth-completion". If you then go to the buffer
>> "SuperGreeterCaller.php", you can get the same result than me with
>> "semanticdb-typecache-dump".
>>
>>
>> A way to check is to get the above output, immediately visit the included
>> file, and use 'bovinate' in there to see what the content is. If it has no
>> types, it won't be in the typecache.  If it does, and you go back and
>> re-request the typecache and the content is there, then there is some
>> update issue.  Those are puzzling to debug.
>>
>> I checked, and bovinate returns the expected types.
>>
>>
>> In your output, I notice that you tags are saved in :members in an order
>> different than the text of the parsed buffer.  Is that a cut and paste
>> error in your email, or is that real?  I also noticed the output excludes
>> an positional information, either in [ start end ] or overlay form.  Is
>> that on purpose?
>>
>> I think the reverse order in :members is not done on purpose. Would it be
>> better to put them on the right order ? Also, I stripped position
>> information to ease reading in the mail, but if you need it I can give you
>> the full result of bovinate.
>>
>>
>>
>> Lastly, if "use" acts both as include and using statement, you could try
>> can use wisent-php-expand-tag to convert the include to also be a 'using'
>> statement at the same location.  That way the scope calculation engine
>> could identify and convert "Greeter" into the other type when found.   I'm
>> guessing a bit about that, so you could just wait until you need it to give
>> it a try.
>>
>> In the PHP semantics, "use" behaves only as a using statement, but as
>> there is no explicit "include" in modern PHP, using it as an include
>> statement too seems to be the best thing I can do to include the aliased
>> type in the scope.  I currently generate a compound "alias" tag in the
>> grammar (because you can write "use A as B, C as D;"), and then for each
>> aliasing I generate a type tag and an include tag as shown in my last mail.
>> It is the result of experimentation of various methods until I find one
>> that works perfectly, so if there a more elegant way do this I'm totally
>> willing to use it.
>>
>> I can't find anything about the "using" tag in the manual. I already saw
>> it in the code for C++ support, is this tag specific to this language ?
>>
>> Thank you again for your help.
>>
>>
>

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

_______________________________________________
Cedet-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cedet-devel