Thread: [CEDET-devel] maybe a bug
Brought to you by:
zappo
From: peng yu <yup...@gm...> - 2009-03-11 15:46:58
|
Hi, Eric. I think I find a bug about smart completion. The below is my code, and I can not get the completion at point "y->" typedef struct STRUCT2 { int a; } STRUCT2; typedef struct STRUCT1 { STRUCT2 m[3]; } STRUCT1; STRUCT1 x; int main(int argc, char * argv[]) { STRUCT2 *y = &x.m[0]; y-> } |
From: yupeng <yup...@gm...> - 2010-01-17 02:09:19
|
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? |
From: Eric M. L. <er...@si...> - 2010-01-17 14:06:15
|
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; > } |
From: peng yu <yup...@gm...> - 2010-01-17 15:09:52
|
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 <er...@si...> > 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; >> } >> > |
From: Eric M. L. <er...@si...> - 2010-01-17 16:24:57
|
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 <er...@si... > <mailto:er...@si...>> > > 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; > } > > |
From: peng yu <yup...@gm...> - 2010-01-18 02:45:59
|
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 <er...@si...> > 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 <er...@si... <mailto: >> er...@si...>> >> >> >> 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; >> } >> >> >> |
From: Eric M. L. <er...@si...> - 2009-03-12 01:04:16
|
>>> peng yu <yup...@gm...> 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: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |