Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

thomas-serre-sonarsource
Copy link
Contributor

No description provided.

@thomas-serre-sonarsource thomas-serre-sonarsource force-pushed the ts/SONARPY-2111/SONARPY-2219 branch 2 times, most recently from 715fcaf to 2814c69 Compare October 22, 2024 09:23
@maksim-grebeniuk-sonarsource maksim-grebeniuk-sonarsource force-pushed the ts/SONARPY-2111/SONARPY-2219 branch 3 times, most recently from c2ef2f0 to 70a3232 Compare October 23, 2024 10:03
@guillaume-dequenne-sonarsource guillaume-dequenne-sonarsource marked this pull request as ready for review October 23, 2024 12:20
@guillaume-dequenne-sonarsource guillaume-dequenne-sonarsource marked this pull request as draft October 23, 2024 12:20
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

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.

@maksim-grebeniuk-sonarsource maksim-grebeniuk-sonarsource force-pushed the ts/SONARPY-2111/SONARPY-2219 branch 6 times, most recently from c1511fb to 2c09e71 Compare October 28, 2024 13:05
Copy link

Quality Gate failed Quality Gate failed

Failed conditions
12 New issues

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarLint SonarLint

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants