GNOME Bugzilla – Bug 617472
doubled items in locals view
Last modified: 2010-07-01 20:33:37 UTC
Created attachment 160171 [details] items locals view while editing plugins/symbol-db/anjuta-tags/c.c file I saw doubled items as in the screenshot. clicking on them brings me at the right locations of symbols but on differnt files. This should of course be avoided and only the real local symbol should be visualized.
The view tries to show parents of any symbol found in the file. For example, classes or structs can have their members defined in the file, yet have their class definitions found in different file. When trying to find the parent of the enum members found in that file, it get's following parents: sqlite> select name, scope_definition_id from symbol where scope_definition_id = 7038; eTokenType|7038 eTokenType|7038 eTokenType|7038 eTokenType|7038 eTokenType|7038 eTokenType|7038 eTokenType|7038 sqlite> That's basically manifestation of bug 615403 Just like we had to work it around for namespaces, I thought about hacking SQL again for enums, but I think it's pointless. We should fix bug 615403 instead properly.
(In reply to comment #1) > The view tries to show parents of any symbol found in the file. For example, > classes or structs can have their members defined in the file, yet have their > class definitions found in different file. > > When trying to find the parent of the enum members found in that file, it get's > following parents: > > sqlite> select name, scope_definition_id from symbol where scope_definition_id > = 7038; > eTokenType|7038 > eTokenType|7038 > eTokenType|7038 > eTokenType|7038 > eTokenType|7038 > eTokenType|7038 > eTokenType|7038 > sqlite> > > That's basically manifestation of bug 615403 > well, I think your query is wrong. You should check *in* that file only for eTokenType. sqlite> select * from symbol join file on symbol.file_defined_id = file.file_id where file_id = 381 and name = 'eTokenType'; 30081|381|eTokenType|108|1|||20816|0|7745|13|-1|-1|1|381|/plugins/symbol-db/anjuta-tags/c.c|1|1|2010-05-03 21:08:45
(In reply to comment #2) > (In reply to comment #1) > > The view tries to show parents of any symbol found in the file. For example, > > classes or structs can have their members defined in the file, yet have their > > class definitions found in different file. > > > > well, I think your query is wrong. > You should check *in* that file only for eTokenType. > If you read my first para in comment #1, you will understand why I think that's not correct. First, the local view is not necessarily showing only the content of the file. It shows content of the file and their parents. The parent's don't necessarily have to be in the same file, as demonstrated by namespaces, classes and structs (yes, in C++ structs can have member methods too, although no one really uses it that way). So, the natural query is: "Select all symbols that are in this file, plus the parents of these local symbols, ...". This bug creates an exception to this rule, and exceptions should be avoided in favor of more well defined structures.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > The view tries to show parents of any symbol found in the file. For example, > > > classes or structs can have their members defined in the file, yet have their > > > class definitions found in different file. > > > > > > > well, I think your query is wrong. > > You should check *in* that file only for eTokenType. > > > If you read my first para in comment #1, you will understand why I think that's > not correct. > > First, the local view is not necessarily showing only the content of the file. > It shows content of the file and their parents. The parent's don't necessarily > have to be in the same file, as demonstrated by namespaces, classes and structs > (yes, in C++ structs can have member methods too, although no one really uses > it that way). So, the natural query is: "Select all symbols that are in this > file, plus the parents of these local symbols, ...". This bug creates an > exception to this rule, and exceptions should be avoided in favor of more well > defined structures. I forgot to mention the 2nd reason. Secondly, bug 615403 fixes this, along with many other manifestations. So, in the end, the real deal is to take care of bug 615403.
*** Bug 620880 has been marked as a duplicate of this bug. ***
Since this bug affects more use cases, like in vala, I fixed the workaround instead of waiting for bug 615403 to resolve. Now, only parents of type 'class' are picked up from outside the file. This means if you use struct as c++ class spanning multiple files, that one isn't going to work, for example. And possibly other corner cases that I don't know yet. Anyways, I suppose that's less of a bug than the vala case. Fixed with commit http://git.gnome.org/browse/anjuta/commit/?id=9ce91d66718fa3282863aaac805d1b8b91d68429