Thread: [CEDET-devel] Disable type-matching in semantic C/C++ completion
Brought to you by:
zappo
From: Oleg O A. <Ole...@ya...> - 2010-03-27 22:18:16
|
Hello, As far as I could understand, semantic tries to "match" types during completion. Unfortunately, sometimes this intelligence filters out possible completions, one of the most common examples are defines. In the following code current CVS version of semantic returns zero completions: #define ABC 0 int f() { int x; x = A ^^^ (try completions here) } Is there a simple way to disable this "type-matching" and if not, what piece of code is responsible for it? Sincerely yours, Oleg Andreev |
From: Eric M. L. <er...@si...> - 2010-03-29 01:18:00
Attachments:
semantic-analyze-complete.patch
|
On 03/27/2010 06:18 PM, Oleg O Andreev wrote: > Hello, > > As far as I could understand, semantic tries to "match" types during > completion. Unfortunately, sometimes this intelligence filters out > possible completions, one of the most common examples are defines. In > the following code current CVS version of semantic returns zero completions: > > #define ABC 0 > > int f() > { > int x; > > x = A > ^^^ (try completions here) > } > > Is there a simple way to disable this "type-matching" and if not, what > piece of code is responsible for it? > Hi, There is no current way to do that. I created the attached patch which will provide "all" completions if the more restricted set of completions doesn't work. It is actually faster to "not" perform the restriction. The change in question seems like the best way to provide the feature you asked for without breaking the existing and presumably desired behavior. On a per-tool basis, it might make sense to have a "get completions list", and a second "ask harder" phase. Each tool would need to decide how it wanted to do that. I can provide the feature if there are tools that could use it well. If you find this patch helps, let me know and I'll commit it. Eric |
From: Lluís <xs...@gm...> - 2010-03-29 10:04:17
|
>> Is there a simple way to disable this "type-matching" and if not, what >> piece of code is responsible for it? [...] > On a per-tool basis, it might make sense to have a "get completions > list", and a second "ask harder" phase. Each tool would need to decide > how it wanted to do that. I can provide the feature if there are tools > that could use it well. This is how, without really knowing how it works, I think that completion should be performed: The text just before point establishes the lookup "namespace". For example: x = partial<completion> triggers completion on the top-level namespace, searching for symbols starting with `partial'; while x = something.partial<completion> and the like (e.g., something->, depending on language) trigger completion on the something namespace, same prefix. Nothing new here. Then, three possible types of matches should be returned: 1) those that have a return type equal to that of `x' (when known) 2) those that have a return type that the language allows to implicitly cast into the type of `x' (when known). On a perfect world, explicit casts should also be detected an possibly treated as in case 1. 3) those that have no known type; e.g., preprocessor macros in C/C++, in the case their return type is not known (which is not necessarily true), or everything in the selected namespace that has the `partial' prefix if the type of `x' is not known. This case would provide a sane fallback when information is incomplete, which should be refined as the language parser matures, or simply means that the language symbols are inherently untyped (e.g., "duck-typing" languages like lisp or python). Whether this approach is disruptive or not given the current infrastructure, I don't know. Read you, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth |
From: Oleg A. <Ole...@ya...> - 2010-03-29 11:12:48
|
Hello, > There is no current way to do that. I created the attached patch which > will provide "all" completions if the more restricted set of completions > doesn't work. It is actually faster to "not" perform the restriction. > The change in question seems like the best way to provide the feature > you asked for without breaking the existing and presumably desired > behavior. > On a per-tool basis, it might make sense to have a "get completions > list", and a second "ask harder" phase. Each tool would need to decide > how it wanted to do that. I can provide the feature if there are tools > that could use it well. > > If you find this patch helps, let me know and I'll commit it. Yes, thank you very much, this patch helps a lot. Best regards, Oleg Andreev |
From: Eric M. L. <er...@si...> - 2010-03-29 11:28:07
|
On 03/29/2010 07:06 AM, Oleg Andreev wrote: > Hello, >> There is no current way to do that. I created the attached patch which >> will provide "all" completions if the more restricted set of completions >> doesn't work. It is actually faster to "not" perform the restriction. >> The change in question seems like the best way to provide the feature >> you asked for without breaking the existing and presumably desired >> behavior. > >> On a per-tool basis, it might make sense to have a "get completions >> list", and a second "ask harder" phase. Each tool would need to decide >> how it wanted to do that. I can provide the feature if there are tools >> that could use it well. >> >> If you find this patch helps, let me know and I'll commit it. > > Yes, thank you very much, this patch helps a lot. Okie dokie. I've commited it then. If anyone finds this new behavior confusing/strange/whatever, please let me know. Eric |