Remove mangledName column from CppAstNode table

[bruntib]

We're not using mangledName for anything. It is mangledNameHash which connects CppAstNode records with CppEntitys. I also think that printing mangled name doesn't help in code comprehension. So I suggest removing this column in order to reduce database size.

[zporky]

Can we generate MangledName from the remaining information? Mangled names _are_ important for comprehension when debugging. What about the mangled name clustering? Does not it use the MangledName field? bruntib <notifications@github.com> ezt írta (időpont: 2020. aug. 2., V, 10:24):

…

We're not using mangledName for anything. It is mangledNameHash which connects CppAstNode records with CppEntitys. I also think that printing mangled name doesn't help in code comprehension. So I suggest removing this column in order to reduce database size. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#417>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTPLCAXOAHTID4BLJUZ5ATR6UPD3ANCNFSM4PSN2N5A> .

[bruntib]

So far we haven't used mangled name for anything. It was not displayed on GUI, and there was no business logic behind it. We used mangledNameHash for everything, and we still have that. As for code comprehension, I think qualified name can be useful, and we have that too. As far as I know, mangled name is not even specified by the standard. Moreover, in the future it would be better using Clang Unified Symbol Reference (USR: https://clang.llvm.org/doxygen/group__CINDEX__CURSOR__XREF.html#details) for identifying symbols. Currently mangled name is generated manually, not only for functions but every other symbol and we're just hoping that our self-made "mangled name" identifies for example the unnamed parameter of a compiler generated function quite uniquely. There was some struggle inventing it so that it's precise enough.
It would be nice if we could eliminate this column, because it greatly decreases database size: 302M -> 264M. So let's continue the discussion to make sure that we really don't need it.

[zporky]

OK, I have got the idea. bruntib <notifications@github.com> ezt írta (időpont: 2020. aug. 3., H, 21:22):

…

So far we haven't used mangled name for anything. It was not displayed on GUI, and there was no business logic behind it. We used mangledNameHash for everything, and we still have that. As for code comprehension, I think qualified name can be useful, and we have that too. As far as I know, mangled name is not even specified by the standard. Moreover, in the future it would be better using Clang Unified Symbol Reference (USR: https://clang.llvm.org/doxygen/group__CINDEX__CURSOR__XREF.html#details) for identifying symbols. Currently mangled name is generated manually, not only for functions but every other symbol and we're just hoping that our self-made "mangled name" identifies for example the unnamed parameter of a compiler generated function quite uniquely. There was some struggle inventing it so that it's precise enough. It would be nice if we could eliminate this column, because it greatly decreases database size: 302M -> 264M. So let's continue the discussion to make sure that we really don't need it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#417 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTPLCFJJOCXOF7NYOQK6WDR64E6NANCNFSM4PSN2N5A> .

[whisperity]

What about the mangled name clustering? Does not it use the MangledName field?

@zporky If you mean #198, no it does not. The clusters are formed as "sets of files", and these sets are used to enhance the results. The clustering algorithm on service side does not affect how symbols are looked up in the first place. (And AFAIK, that does not use the explicit mangledname, either...) The cluster also is given a set of candidate symbols and the set of files (to which those symbols belong to), and creates the three-tier breakdown based on that.