CEDET

>>> peng yu <yupeng820921@...> seems to think that:
>STRUCT1 x;
>int main(int argc, char * argv[])
>{
>    STRUCT2 *y = &x.m[0];
>    y->
>}

Hi Peng!

  Whenever you encounter a suspicious problem with the smart
completion, run the command:

M-x semantic-analyze-debug-assist

  This will attempt to show many possible ways that the completion may
have failed.  In this case, the local variable parser doesn't
recognize "y".  As it turns out, complex syntaxes in variable
declaration assignment confuse the parser because it is incomplete.
This was just another instance.  In this case deleting the [0] is all
it takes.

  I have checked in a fix to add [] support here.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

this is a c program file test1.c:
--------------------------------------------------------------------------
struct snd_device_ops {
	int (*dev_disconnect)(struct snd_device *dev);
};

#define snd_device(n) list_entry(n, struct snd_device, list)

int my_variable;

void snd_power_lock( void )
{
    my_variable = 0;
}

---------------------------------------------------------------------------

I move the cursor to the line "my_variable = 0;" , and just above the
variable "my_variable", then I type "M-x semantic-ia-fast-jump", it can
not find the define of "my_variable", and emacs has no respone until I
type "C-g". If I remove the first 5 lines, all the things will be ok.

Is it a bug?

Hi,

I see the problem, but can you explain this C code?

The issue is that snd_device is #defined after it is used in the 
structure, and the use in the structure doesn't have enough arguments, 
and that's making CEDET a bit cranky.

Is it supposed to be defined in that order?  Is snd_device also a 
non-macro somewhere else?

I'll try to fix the hang, but I'd like to understand how the code is 
supposed to work too.

Thanks
Eric

yupeng wrote:
> this is a c program file test1.c:
> --------------------------------------------------------------------------
> struct snd_device_ops {
> 	int (*dev_disconnect)(struct snd_device *dev);
> };
> 
> #define snd_device(n) list_entry(n, struct snd_device, list)
> 
> int my_variable;
> 
> void snd_power_lock( void )
> {
>     my_variable = 0;
> }

Hi.

In fact, the #define is not used by the structure snd_device_ops,  the
snd_device in the struture is be defined in some other place.

This code is a part of alsa (advanture linux sound driver, an open source
project).

Now I am working on write a sound driver in linux, and I setup a
ede-cpp-root-project on my code, then I use semantic-ia-fast-jump to browse
my code. I find sometimes I loss the respond of emacs when I run the
semantic-ia-fast-jump command, so I extract my code to find which part of
code cause this problem, at last, I get the code I sent to you in test1.c.
This piece of code is not written by me, I don't know why the author write
the code in this from too, but if you can fix this problem, it will be very
helpful for me.

BR.
yupeng.

2010/1/17 Eric M. Ludlam <eric@...>

> Hi,
>
> I see the problem, but can you explain this C code?
>
> The issue is that snd_device is #defined after it is used in the structure,
> and the use in the structure doesn't have enough arguments, and that's
> making CEDET a bit cranky.
>
> Is it supposed to be defined in that order?  Is snd_device also a non-macro
> somewhere else?
>
> I'll try to fix the hang, but I'd like to understand how the code is
> supposed to work too.
>
> Thanks
> Eric
>
>
> yupeng wrote:
>
>> this is a c program file test1.c:
>> --------------------------------------------------------------------------
>> struct snd_device_ops {
>>        int (*dev_disconnect)(struct snd_device *dev);
>> };
>>
>> #define snd_device(n) list_entry(n, struct snd_device, list)
>>
>> int my_variable;
>>
>> void snd_power_lock( void )
>> {
>>    my_variable = 0;
>> }
>>
>

I've checked in a "fix" that just puts a recursion limit into the macro 
expansion.  This should solve your problem.  I'll need to find a better 
solution that doesn't need this limit though.

Enjoy
Eric

peng yu wrote:
> Hi.
> 
> In fact, the #define is not used by the structure snd_device_ops,  the 
> snd_device in the struture is be defined in some other place.
> 
> This code is a part of alsa (advanture linux sound driver, an open 
> source project).
> 
> Now I am working on write a sound driver in linux, and I setup a 
> ede-cpp-root-project on my code, then I use semantic-ia-fast-jump to 
> browse my code. I find sometimes I loss the respond of emacs when I run 
> the semantic-ia-fast-jump command, so I extract my code to find which 
> part of code cause this problem, at last, I get the code I sent to you 
> in test1.c. This piece of code is not written by me, I don't know why 
> the author write the code in this from too, but if you can fix this 
> problem, it will be very helpful for me.
> 
> BR.
> yupeng.
> 
> 2010/1/17 Eric M. Ludlam <eric@... 
> <mailto:eric@...>>
> 
>     Hi,
> 
>     I see the problem, but can you explain this C code?
> 
>     The issue is that snd_device is #defined after it is used in the
>     structure, and the use in the structure doesn't have enough
>     arguments, and that's making CEDET a bit cranky.
> 
>     Is it supposed to be defined in that order?  Is snd_device also a
>     non-macro somewhere else?
> 
>     I'll try to fix the hang, but I'd like to understand how the code is
>     supposed to work too.
> 
>     Thanks
>     Eric
> 
> 
>     yupeng wrote:
> 
>         this is a c program file test1.c:
>         --------------------------------------------------------------------------
>         struct snd_device_ops {
>                int (*dev_disconnect)(struct snd_device *dev);
>         };
> 
>         #define snd_device(n) list_entry(n, struct snd_device, list)
> 
>         int my_variable;
> 
>         void snd_power_lock( void )
>         {
>            my_variable = 0;
>         }
> 
>

Hi.

I check out from CVS, and your fix can work very well, thank you!

If you find the better solution, please let me know, I'd like to use the
"perfect" solution.

2010/1/18 Eric M. Ludlam <eric@...>

> I've checked in a "fix" that just puts a recursion limit into the macro
> expansion.  This should solve your problem.  I'll need to find a better
> solution that doesn't need this limit though.
>
> Enjoy
> Eric
>
> peng yu wrote:
>
>> Hi.
>>
>> In fact, the #define is not used by the structure snd_device_ops,  the
>> snd_device in the struture is be defined in some other place.
>>
>> This code is a part of alsa (advanture linux sound driver, an open source
>> project).
>>
>> Now I am working on write a sound driver in linux, and I setup a
>> ede-cpp-root-project on my code, then I use semantic-ia-fast-jump to browse
>> my code. I find sometimes I loss the respond of emacs when I run the
>> semantic-ia-fast-jump command, so I extract my code to find which part of
>> code cause this problem, at last, I get the code I sent to you in test1.c.
>> This piece of code is not written by me, I don't know why the author write
>> the code in this from too, but if you can fix this problem, it will be very
>> helpful for me.
>>
>> BR.
>> yupeng.
>>
>> 2010/1/17 Eric M. Ludlam <eric@... <mailto:
>> eric@...>>
>>
>>
>>    Hi,
>>
>>    I see the problem, but can you explain this C code?
>>
>>    The issue is that snd_device is #defined after it is used in the
>>    structure, and the use in the structure doesn't have enough
>>    arguments, and that's making CEDET a bit cranky.
>>
>>    Is it supposed to be defined in that order?  Is snd_device also a
>>    non-macro somewhere else?
>>
>>    I'll try to fix the hang, but I'd like to understand how the code is
>>    supposed to work too.
>>
>>    Thanks
>>    Eric
>>
>>
>>    yupeng wrote:
>>
>>        this is a c program file test1.c:
>>
>>  --------------------------------------------------------------------------
>>        struct snd_device_ops {
>>               int (*dev_disconnect)(struct snd_device *dev);
>>        };
>>
>>        #define snd_device(n) list_entry(n, struct snd_device, list)
>>
>>        int my_variable;
>>
>>        void snd_power_lock( void )
>>        {
>>           my_variable = 0;
>>        }
>>
>>
>>