Thread: [cedet-semantic] Cannot find types for `"a"'
Brought to you by:
zappo
From: Dave M. <dav...@gm...> - 2008-04-30 13:09:44
|
The code is: ------------------------------------------------------------- #include <cstdio> #include <cstdlib> #include <cstring> struct Ops { typedef void *(*f_copy)(void *); f_copy copy; }; struct Foo { int i; Foo(): i(17) {} }; template<typename T> void *my_copy(void *a) { void *res = new T; memcpy(res, a, sizeof(T)); return res; } int main() { Ops ops; ops.copy = my_copy<Foo>; Foo *a, b; b.i = 10; a = static_cast<Foo *>(ops.copy(&b)); printf("a->i %d\n", a-> return EXIT_SUCCESS; } ------------------------------------------------------------- For some reason cedet tell me that it Cannot find types for 'a'. CEDET Version: 1.0pre4 Requested File Loaded Package Version Version Version ---------------------------------------------------------- cedet: 1.0pre4 ok ok cogre: 0.5 0.6 Not Loaded ede: 1.0pre4 1.0pre5 1.0pre5 eieio: 1.0 1.0.1 1.0.1 semantic: 2.0pre4 2.0pre5 2.0pre5 speedbar: 1.0.1 1.0.2 1.0.2 srecode: 0.1 ok ok cedet-contrib: 1.0pre4 1.0pre5 Not Loaded GNU Emacs 22.2.1 |
From: Eric M. L. <er...@si...> - 2008-04-30 15:09:42
|
>>> "Dave Milter" <dav...@gm...> seems to think that: >The code is: >------------------------------------------------------------- [ ... ] >int main() >{ > Ops ops; > ops.copy = my_copy<Foo>; > Foo *a, b; > b.i = 10; > a = static_cast<Foo *>(ops.copy(&b)); > printf("a->i %d\n", a-> > > return EXIT_SUCCESS; >} >------------------------------------------------------------- Sometimes incomplete parenthesis matching can prevent Semantic from knowing you are inside a function, and restrict the things it can complete on. In this case, adding a ) would help. Because this is the last function in the file, Semantic tries to assume you mean this to be all one thing, and will try to provide the function main with the unterminated code body. Anyway, for me completion worked, and I got an "i" as a completion option. If you do: C-u M-x bovinate RET it will force a full reparse. If completion then works, then what you have found is some sort of incremental parsing error which will be challenging to find new repro steps for. >For some reason cedet tell me that it Cannot find types for 'a'. >CEDET Version: 1.0pre4 The command: M-x semantic-analyze-current-context RET will provide a nice output that sometimes indicates where it fell over. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Dave M. <dav...@gm...> - 2008-04-30 16:47:55
|
On 4/30/08, Eric M. Ludlam <er...@si...> wrote: > >>> "Dave Milter" <dav...@gm...> seems to think that: > >The code is: > >------------------------------------------------------------- > [ ... ] > > >int main() > >{ > > Ops ops; > > ops.copy = my_copy<Foo>; > > Foo *a, b; > > b.i = 10; > > a = static_cast<Foo *>(ops.copy(&b)); > > printf("a->i %d\n", a-> > > > > return EXIT_SUCCESS; > >} > >------------------------------------------------------------- > > > Sometimes incomplete parenthesis matching can prevent Semantic from > knowing you are inside a function, and restrict the things it can > complete on. In this case, adding a ) would help. > > Because this is the last function in the file, Semantic tries to > assume you mean this to be all one thing, and will try to provide > the function main with the unterminated code body. > > Anyway, for me completion worked, and I got an "i" as a completion > option. > > If you do: > > C-u M-x bovinate RET > > it will force a full reparse. If completion then works, then what you > have found is some sort of incremental parsing error which will be > challenging to find new repro steps for. > > > >For some reason cedet tell me that it Cannot find types for 'a'. > >CEDET Version: 1.0pre4 > > > > The command: > > M-x semantic-analyze-current-context RET > > will provide a nice output that sometimes indicates where it fell > over. > Yeah, "bovinate" or ");" at the end of line helps, but creating new file, open in new buffer, and things do not work again, so it is reprodusible, by the way I use semantic-ia-complete-symbol-menu to show possible completetions, analyze-current-context show: Context Type: #<semantic-analyze-context context> Bounds: (488 . 488) Prefix: "a" "" Prefix Classes: 'type -------- |
From: Eric M. L. <er...@si...> - 2008-04-30 19:45:48
|
>>> "Dave Milter" <dav...@gm...> seems to think that: >On 4/30/08, Eric M. Ludlam <er...@si...> wrote: [ ... ] >> The command: >> >> M-x semantic-analyze-current-context RET >> >> will provide a nice output that sometimes indicates where it fell >> over. >> > > >Yeah, "bovinate" or ");" at the end of line helps, >but creating new file, open in new buffer, and things do not work again, >so it is reprodusible, by the way I use >semantic-ia-complete-symbol-menu to show possible completetions, > >analyze-current-context show: >Context Type: #<semantic-analyze-context context> >Bounds: (488 . 488) >Prefix: "a" > "" >Prefix Classes: 'type >-------- > I'm beginning to see the problem now. When "typing" new code, the incremental parser is used. It will not parse anything with lexical errors. This is for the case where in the middle of some huge file, in some function, you might type in: if(a.-!- and if it allowed the broken lexical state, all data after that point would be lost. Your case is that you are typing fast enough, that the idle parser doesn't have a chance to run when the lexical state is ok, and thus allow the incremental parser to get the right answer. Unfortunately, I think the first use-case trumps the second. There might be something clever to do, like binding ) and } to also do an incremental parse to clean this up, but that feels kind of heavy-weight. Basically, a lexically clean parse is needed before completion works. Perhaps there is some sort of highlighting that would make this more observable so new users know what to do? Any thoughts out there? Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Dave M. <dav...@gm...> - 2008-05-02 20:19:06
|
On 4/30/08, Eric M. Ludlam <er...@si...> wrote: > >>> "Dave Milter" <dav...@gm...> seems to think that: > >On 4/30/08, Eric M. Ludlam <er...@si...> wrote: > > [ ... ] > > >> The command: > >> > >> M-x semantic-analyze-current-context RET > >> > >> will provide a nice output that sometimes indicates where it fell > >> over. > >> > > > > > >Yeah, "bovinate" or ");" at the end of line helps, > >but creating new file, open in new buffer, and things do not work again, > >so it is reprodusible, by the way I use > >semantic-ia-complete-symbol-menu to show possible completetions, > > > >analyze-current-context show: > >Context Type: #<semantic-analyze-context context> > >Bounds: (488 . 488) > >Prefix: "a" > > "" > >Prefix Classes: 'type > >-------- > > > > > I'm beginning to see the problem now. When "typing" new code, the > incremental parser is used. It will not parse anything with lexical > errors. This is for the case where in the middle of some huge file, > in some function, you might type in: > > if(a.-!- > > and if it allowed the broken lexical state, all data after that point > would be lost. > > Your case is that you are typing fast enough, that the idle parser > doesn't have a chance to run when the lexical state is ok, and thus > allow the incremental parser to get the right answer. > > Unfortunately, I think the first use-case trumps the second. There > might be something clever to do, like binding ) and } to also do an > incremental parse to clean this up, but that feels kind of > heavy-weight. Basically, a lexically clean parse is needed before > completion works. Perhaps there is some sort of highlighting that > would make this more observable so new users know what to do? > > Any thoughts out there? > > Hm, may be this is stupid idea, but if run "bovinate" I get right list of possible completetions, why not, if there are no completion, run once "bovinate" and only then, if all bad, report about it? |
From: Eric M. L. <er...@si...> - 2008-05-03 12:47:53
|
>>> "Dave Milter" <dav...@gm...> seems to think that: >On 4/30/08, Eric M. Ludlam <er...@si...> wrote: >> >>> "Dave Milter" <dav...@gm...> seems to think that: >> >On 4/30/08, Eric M. Ludlam <er...@si...> wrote: >> >> [ ... ] >> >> >> The command: >> >> >> >> M-x semantic-analyze-current-context RET >> >> >> >> will provide a nice output that sometimes indicates where it fell >> >> over. >> >> >> > >> > >> >Yeah, "bovinate" or ");" at the end of line helps, >> >but creating new file, open in new buffer, and things do not work again, >> >so it is reprodusible, by the way I use >> >semantic-ia-complete-symbol-menu to show possible completetions, >> > >> >analyze-current-context show: >> >Context Type: #<semantic-analyze-context context> >> >Bounds: (488 . 488) >> >Prefix: "a" >> > "" >> >Prefix Classes: 'type >> >-------- >> > >> >> >> I'm beginning to see the problem now. When "typing" new code, the >> incremental parser is used. It will not parse anything with lexical >> errors. This is for the case where in the middle of some huge file, >> in some function, you might type in: >> >> if(a.-!- >> >> and if it allowed the broken lexical state, all data after that point >> would be lost. >> >> Your case is that you are typing fast enough, that the idle parser >> doesn't have a chance to run when the lexical state is ok, and thus >> allow the incremental parser to get the right answer. >> >> Unfortunately, I think the first use-case trumps the second. There >> might be something clever to do, like binding ) and } to also do an >> incremental parse to clean this up, but that feels kind of >> heavy-weight. Basically, a lexically clean parse is needed before >> completion works. Perhaps there is some sort of highlighting that >> would make this more observable so new users know what to do? >> >> Any thoughts out there? >> >> > >Hm, may be this is stupid idea, >but if run "bovinate" I get right list of possible completetions, >why not, if there are no completion, >run once "bovinate" and only then, if all bad, report about it? > If you had the above syntax, and a full reparse occurred, it would wipe out all parsed data after point. In your case, there are no more functions after point, so the solution would work, but be limited to that case. There might be a clever way to allow some restricted incremental parsing to get the expected (though not correct) answer, but I'd be hesitant since it'd be filling the tag structures with corrupted data. Though I guess that already happens w/ the full parse. You could turn on `global-semantic-highlight-edits-mode' and get some visual feedback about the parser state. Then it'd be more obvious when there was an issue. I'll add this to my todo list to try and figure out. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Dave M. <dav...@gm...> - 2008-05-03 20:16:36
|
On 5/3/08, Eric M. Ludlam <er...@si...> wrote: > >>> "Dave Milter" <dav...@gm...> seems to think that: > >On 4/30/08, Eric M. Ludlam <er...@si...> wrote: > >> >>> "Dave Milter" <dav...@gm...> seems to think that: > >> >On 4/30/08, Eric M. Ludlam <er...@si...> wrote: > >> > >> [ ... ] > >> > >> >> The command: > >> >> > >> >> M-x semantic-analyze-current-context RET > >> >> > >> >> will provide a nice output that sometimes indicates where it fell > >> >> over. > >> >> > >> > > >> > > >> >Yeah, "bovinate" or ");" at the end of line helps, > >> >but creating new file, open in new buffer, and things do not work again, > >> >so it is reprodusible, by the way I use > >> >semantic-ia-complete-symbol-menu to show possible completetions, > >> > > >> >analyze-current-context show: > >> >Context Type: #<semantic-analyze-context context> > >> >Bounds: (488 . 488) > >> >Prefix: "a" > >> > "" > >> >Prefix Classes: 'type > >> >-------- > >> > > >> > >> > >> I'm beginning to see the problem now. When "typing" new code, the > >> incremental parser is used. It will not parse anything with lexical > >> errors. This is for the case where in the middle of some huge file, > >> in some function, you might type in: > >> > >> if(a.-!- > >> > >> and if it allowed the broken lexical state, all data after that point > >> would be lost. > >> > >> Your case is that you are typing fast enough, that the idle parser > >> doesn't have a chance to run when the lexical state is ok, and thus > >> allow the incremental parser to get the right answer. > >> > >> Unfortunately, I think the first use-case trumps the second. There > >> might be something clever to do, like binding ) and } to also do an > >> incremental parse to clean this up, but that feels kind of > >> heavy-weight. Basically, a lexically clean parse is needed before > >> completion works. Perhaps there is some sort of highlighting that > >> would make this more observable so new users know what to do? > >> > >> Any thoughts out there? > >> > >> > > > >Hm, may be this is stupid idea, > >but if run "bovinate" I get right list of possible completetions, > >why not, if there are no completion, > >run once "bovinate" and only then, if all bad, report about it? > > > > > If you had the above syntax, and a full reparse occurred, it would > wipe out all parsed data after point. In your case, there are no more > functions after point, so the solution would work, but be limited to > that case. > Yes, but if I have something bellow point, and I too fast go to this point, before semantic can do its work again, it again call bovinate, if not found suitable completetion, and again all will work again. |