-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SONARPY-2219 Pass the result of the type inference for a Python file to ProjectLevelTypesTable #2090
base: master
Are you sure you want to change the base?
Conversation
715fcaf
to
2814c69
Compare
2814c69
to
99f2870
Compare
155a04b
to
0fb0591
Compare
c2ef2f0
to
70a3232
Compare
3c4fa83
to
15281f4
Compare
assertThat(ambiguousDescriptor.name()).isEqualTo("myUnionType"); | ||
assertThat(ambiguousDescriptor.fullyQualifiedName()).isEqualTo("foo.myUnionType"); | ||
assertThat(ambiguousDescriptor.kind()).isEqualTo(Descriptor.Kind.AMBIGUOUS); | ||
// TODO SONARPY-2225 the two class types in the union are rigorously the same but the converter creates an ambigouous descriptor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it is to be expected since we don't implement equals
for PythonType
and expect the unicity of PythonType objects for each available type.
I guess that means that we'd have an ambiguous descriptor in the case where there are 2 definitions that are strictly identical:
if x:
class A: ...
else:
class A: ...
However, I think it's okay to accept this behavior for now. If this prevents proper resolution in some cases, we can always implement something that would merge types that are essentially identical.
65a0157
to
6115ada
Compare
6115ada
to
a48d415
Compare
a48d415
to
c1511fb
Compare
Quality Gate failedFailed conditions See analysis details on SonarQube Catch issues before they fail your Quality Gate with our IDE extension SonarLint |
No description provided.