SONARPY-2331 Implement setting metaclassFQN field for ClassType to ClassDescriptor conversion #2153
Conversation
maksim-grebeniuk-sonarsource
force-pushed
the
SONARPY-2331
branch
2 times, most recently
from
15e4093
to
a15572e
Compare
maksim-grebeniuk-sonarsource
requested a review
from guillaume-dequenne-sonarsource
| return new ClassDescriptor(symbolName, symbolFqn, | ||
| superClasses, | ||
| memberDescriptors, | ||
| type.hasDecorators(), | ||
| type.definitionLocation().orElse(null), | ||
| hasSuperClassWithoutDescriptor, | ||
| type.hasMetaClass(), | ||
| null, | ||
| metaclassFQN, |
There was a problem hiding this comment.
Not strictly related to the PR, but I see the metaclassFQN method is not annotated as CheckForNull which is probably misleading.
Also, I'm a bit concerned that we're going to cement the usage of the metaclassFQN somewhat inconsistently (because importType.importPath() does not produce a fully qualified name according to our definition). I think it's okay for now, but we should keep in mind that this probably need to change eventually (like for decorators).
| @@ -1125,6 +1125,18 @@ class Field(MetaField): ... | |||
| assertThat(symbol.hasUnresolvedTypeHierarchy()).isTrue(); | |||
| } | |||
|
|
|||
| @Test | |||
| void class_wth_metaclass() { | |||
There was a problem hiding this comment.
It would probably make sense to have some other tests where the metaclass is local or unresolved. I know it's basically testing typeFqn again, but since it's not a fully valid implementation (cf above comment), we probably want to have it documented.
maksim-grebeniuk-sonarsource
force-pushed
the
SONARPY-2331
branch
from
a15572e
to
0a6af73
Compare
maksim-grebeniuk-sonarsource
requested a review
from guillaume-dequenne-sonarsource
…assDescriptor conversion
maksim-grebeniuk-sonarsource
force-pushed
the
SONARPY-2331
branch
from
75e97c2
to
510214f
Compare
|
SONARPY-2331