Avoid copying symbols that come from the project table and fix bug for ambiguous descriptors with null FQN#1040
Conversation
a4771fc to
7010b94
Compare
…r ambiguous descriptors with null FQN
7010b94 to
6560b1a
Compare
andrea-guarino-sonarsource
left a comment
There was a problem hiding this comment.
LGTM, I think it's ok to merge this PR to fix the problems we have on Peach. However, I think we should clean-up DescriptorUtils before shipping it to production
There was a problem hiding this comment.
Maybe we could call the copyWithoutUsages inside typeshedSymbolWithFQN?
There was a problem hiding this comment.
I think we should clean-up a bit those static methods that create symbols: this could become a Builder Class where we keep projectLevelSymbolTable, createdSymbolsByDescriptor and createdSymbolsByFqn as internal states. I don't think we need to do it in this PR, however believe it's important to do it before releasing new version to avoid adding more technical dept.
Let's add a TODO comment and maybe a task ticket in the Kanbar.
|
SonarQube Quality Gate
|
…match their assigned variable names (#1040) GitOrigin-RevId: 6c637df3b657e7959d17bda21463f8ce4a4bb3f7
Thanks to descriptors, symbols from the project symbol table are always new and shouldn't require any copy logic (
copyWithoutUsageorcopySymbol).This PR also fix a bug when a descriptor within an ambiguous descriptor has a
nullFQN and cannot be retrieved properly bycreatedSymbols.