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

Embedded class is incorrectly recognized as Unknown under particular conditions #2157

Closed
Azureblade3808 opened this issue Dec 10, 2021 · 7 comments
Labels
bug Something isn't working fixed in next version (main) A fix has been implemented and will appear in an upcoming version

Comments

@Azureblade3808
Copy link

Azureblade3808 commented Dec 10, 2021

Environment data

  • Language Server version: 2021.12.2-pre.1
  • OS and version: Windows 7
  • Python version (& distribution if applicable, e.g. Anaconda): 3.8.12 Anaconda

Sample code

from __future__ import annotations

def b0() -> A.B: ...
def c0() -> A.B.C: ...

class A:
    class B:
        class C:
            ...
    def b(self) -> A.B: ...
    def c(self) -> A.B.C: ...

def b1() -> A.B: ...
def c1() -> A.B.C: ...

# _ = b0()
# _ = c0()
# _ = A().b()
# _ = A().c()

Expected behavior

Every type is correctly recognized.

Actual behavior

When you hover on an embedded part (e.g. B or C in A.B.C) of the result types of b0, c0, A.b and A.c, you will find that it is recognized as Unknown.

b1 and c1 are OK.

All become right once the last lines are recovered from being commented out.
For the last several commented lines, if you uncomment a line, the result type of the corresponding function / method SOMETIMES becomes right, while I didn't find a way to ensure that.

And to my surprise, this issue only exists for return types, but not argument types.

Edit:
Change the description of uncommenting the last several lines.

@erictraut
Copy link
Contributor

Thanks for the bug report. This occurs only when from __future__ import annotations is in effect and the return type annotation refers to a forward-declared symbol and the type of the annotation is evaluated prior to the forward-declared symbol by Pyright's lazy type evaluator.

This will be fixed in the next release.

@erictraut erictraut added bug Something isn't working fixed in next version (main) A fix has been implemented and will appear in an upcoming version and removed triage labels Dec 10, 2021
@bschnurr
Copy link
Member

This issue has been fixed in version 2021.12.1, which we've just released. You can find the changelog here: CHANGELOG.md

@Azureblade3808
Copy link
Author

Azureblade3808 commented Dec 12, 2021

This issue has been fixed in version 2021.12.1, which we've just released. You can find the changelog here: CHANGELOG.md

Is the fix not published yet? For this issue was found in 2021.12.1 and I haven't see a new version of 2021.12.2 in case there's a typo.

@erictraut
Copy link
Contributor

This was fixed after Pylance 2021.12.1 was released.

@erictraut erictraut reopened this Dec 12, 2021
@Azureblade3808
Copy link
Author

Are you talking about 2021.12.2 instead of 2021.12.1?

2021.12.1 is just the version of Pylance which the issue was found in.

@erictraut
Copy link
Contributor

@Azureblade3808, the fix will be in Pylance version 2021.12.2 which will be released next week. (Typically we publish Pylance on Wednesday or Thursday.)

@bschnurr, it looks like you closed this bug after publishing 2021.12.1, but this fix was introduced afterward. It's included in Pyright 1.1.195.

@bschnurr
Copy link
Member

Sorry about that. New Pylance version 2021.12.2 was just released.
You can find the changelog here: CHANGELOG.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fixed in next version (main) A fix has been implemented and will appear in an upcoming version
Projects
None yet
Development

No branches or pull requests

3 participants