CEDET

Consider the following case:

--------------- parent.h -----------------
class parent {
public:
  void parent_fun () { };
};
------------------------------------------

--------------- test.cpp -----------------
#include "parent.h"

class child : public parent {
public:
  void child_fun () { };
};

void fun()
{
  child c;
  c. // <--- complete here
}
------------------------------------------

I only get the completion for 'child_fun', but not for 'parent_fun'. If
I move the 'class parent' definition into test.cpp, it will show both.

I think the problem is that when collecting completions through

	(setq c (semantic-find-tags-for-completion
		 completetext
		 (semantic-analyze-scoped-type-parts completetexttype scope)
		 ))

(from semantic-analyze-possible-completions-default)

the searching is only done in the local scope, which doesn't include the
definition from 'parent.h' in this case.

I guess if the parent cannot be found in the local scope, we have to
introduce a typecache search somewhere?

Regards,
David

Re: [CEDET-devel] Problems with completion of inherited functions outside of local scope From: Eric M. Ludlam <eric@si...> - 2009-10-08 01:23 Thanks for taking time to create this use case. When I put parent.h and child.cpp into the same directory, I got both child_fun, and parent_fun in my completion list when using `semantic-analyze-possible-completions'. In reading your text, I am suspicious that you are not using that fcn for completion, but something else? What is it? Thanks Eric On Wed, 2009-10-07 at 17:37 +0200, David Engster wrote: > Consider the following case: > > --------------- parent.h ----------------- > class parent { > public: > void parent_fun () { }; > }; > ------------------------------------------ > > --------------- test.cpp ----------------- > #include "parent.h" > > class child : public parent { > public: > void child_fun () { }; > }; > > void fun() > { > child c; > c. // <--- complete here > } > ------------------------------------------ > > I only get the completion for 'child_fun', but not for 'parent_fun'. If > I move the 'class parent' definition into test.cpp, it will show both. > > I think the problem is that when collecting completions through > > (setq c (semantic-find-tags-for-completion > completetext > (semantic-analyze-scoped-type-parts completetexttype scope) > )) > > (from semantic-analyze-possible-completions-default) > > the searching is only done in the local scope, which doesn't include the > definition from 'parent.h' in this case. > > I guess if the parent cannot be found in the local scope, we have to > introduce a typecache search somewhere? > > Regards, > David > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] Problems with completion of inherited functions outside of local scope From: David Engster <deng@ra...> - 2009-10-08 09:42 Eric M. Ludlam <eric@...> writes: > Thanks for taking time to create this use case. When I put parent.h and > child.cpp into the same directory, I got both child_fun, and parent_fun > in my completion list when using > `semantic-analyze-possible-completions'. You're right. I'm on a different machine now, and here it indeed works. I don't know what happened; maybe I still had some local changes there... However, I think I finally figured out the real culprit in wxWidget. The 'child' definition is in another header, but in that one the parent definition is *not* included: --------------- parent.h ----------------- class parent { public: void parent_fun () { }; }; ------------------------------------------ --------------- child.h ------------------ // No #include of parent.h ! class child : public parent { public: void child_fun () { }; }; ------------------------------------------ --------------- test.cpp ----------------- #include "parent.h" #include "child.h" void fun() { child c; c. // <--- complete here } ------------------------------------------ Regards, David

Re: [CEDET-devel] Problems with completion of inherited functions outside of local scope From: Eric M. Ludlam <eric@si...> - 2009-10-08 11:40 Hi, This I can now replicate this. I suspect this is caused by all that work we did to restrict the search for parent classes based on the context of the issuing class. (For namespaces, aliases, etc.) I suspect semantic-analyze-fcn.el line 296. This would imply that if that call fails, we do whatever was in this history of this file, or vice-versa. I probably won't be able to look into this in detail till next week sometime. Eric On Thu, 2009-10-08 at 11:42 +0200, David Engster wrote: > Eric M. Ludlam <eric@...> writes: > > Thanks for taking time to create this use case. When I put parent.h and > > child.cpp into the same directory, I got both child_fun, and parent_fun > > in my completion list when using > > `semantic-analyze-possible-completions'. > > You're right. I'm on a different machine now, and here it indeed > works. I don't know what happened; maybe I still had some local changes > there... > > However, I think I finally figured out the real culprit in wxWidget. The > 'child' definition is in another header, but in that one the parent > definition is *not* included: > > --------------- parent.h ----------------- > class parent { > public: > void parent_fun () { }; > }; > ------------------------------------------ > > --------------- child.h ------------------ > // No #include of parent.h ! > class child : public parent { > public: > void child_fun () { }; > }; > ------------------------------------------ > > --------------- test.cpp ----------------- > #include "parent.h" > #include "child.h" > > void fun() > { > child c; > c. // <--- complete here > } > ------------------------------------------ > > Regards, > David > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] Problems with completion of inherited functions outside of local scope From: David Engster <deng@ra...> - 2009-10-08 12:58 Eric M. Ludlam <eric@...> writes: > This I can now replicate this. I suspect this is caused by all that > work we did to restrict the search for parent classes based on the > context of the issuing class. (For namespaces, aliases, etc.) I > suspect semantic-analyze-fcn.el line 296. This would imply that if that > call fails, we do whatever was in this history of this file, or > vice-versa. Yes, it's a regression. I tested this with 1.0pre6, and it worked there. However, I don't see how that part of semantic-analyze-fcn.el is involved. Instead, I could track it down to the change in semantic-analyze-scoped-inherited-tag-map, where you introduced the 'mini scope': Date: Tue Aug 18 03:07:03 2009 +0000 (semantic-analyze-scoped-inherited-tag-map): Add section to calculate a new miniscope to use when looking up the parent in case the name provided in the parent of TYPE can only be found in that scope. I'm a bit puzzled, since next to the new 'mini' scope it also queries the original scope: (or (semantic-analyze-find-tag ps 'type tmpscope) ;; A backup hack. (semantic-analyze-find-tag ps 'type scope)) But it seems this is somehow not working. Regards, David

Re: [CEDET-devel] Problems with completion of inherited functions outside of local scope From: Eric M. Ludlam <eric@si...> - 2009-10-08 15:36 Thanks for pointing that out. You are right. The calculation of the miniscope moved point, which invalidated the original scope, preventing it from providing the right kind of data. I checked in a change using save-excursion which re-enabled your test case. I still need to add some tests though. Now I worry that the moved point is needed for something related to the tmpscope, but none of my tests caught such a thing. I hadn't realized that cursor location was still important in this code. Eric On Thu, 2009-10-08 at 14:58 +0200, David Engster wrote: > Eric M. Ludlam <eric@...> writes: > > This I can now replicate this. I suspect this is caused by all that > > work we did to restrict the search for parent classes based on the > > context of the issuing class. (For namespaces, aliases, etc.) I > > suspect semantic-analyze-fcn.el line 296. This would imply that if that > > call fails, we do whatever was in this history of this file, or > > vice-versa. > > Yes, it's a regression. I tested this with 1.0pre6, and it worked > there. However, I don't see how that part of semantic-analyze-fcn.el is > involved. Instead, I could track it down to the change in > semantic-analyze-scoped-inherited-tag-map, where you introduced the > 'mini scope': > > Date: Tue Aug 18 03:07:03 2009 +0000 > > (semantic-analyze-scoped-inherited-tag-map): > Add section to calculate a new miniscope to use when looking up the > parent in case the name provided in the parent of TYPE can only be > found in that scope. > > I'm a bit puzzled, since next to the new 'mini' scope it also queries > the original scope: > > (or (semantic-analyze-find-tag ps 'type tmpscope) > ;; A backup hack. > (semantic-analyze-find-tag ps 'type scope)) > > But it seems this is somehow not working. > > Regards, > David > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel

1 message has been excluded from this view by a project administrator.