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

Should check nested functions #61

Closed
PeterJCLaw opened this issue May 27, 2018 · 5 comments
Closed

Should check nested functions #61

PeterJCLaw opened this issue May 27, 2018 · 5 comments
Labels
enhancement Improvements and feature requests

Comments

@PeterJCLaw
Copy link

PeterJCLaw commented May 27, 2018

python: 3.5.2, 3.6.5
pyre: 0.0.7 (from pip list)

Given a file thing.py:

def outer() -> str:
    def inner(x: int, y: str) -> str:
        return x
    return inner(42, None)

outer()

# Copy of 'inner' to prove that it errors at the top level
def outer_inner(x: int, y: str) -> str:
    return x

outer_inner(42, None)

I'd expect to get errors from the bad types in the nested inner function. For reference, here's what mypy (0.600) outputs:

$ mypy thing.py 
thing.py:3: error: Incompatible return value type (got "int", expected "str")
thing.py:4: error: Argument 2 to "inner" has incompatible type "None"; expected "str"
thing.py:10: error: Incompatible return value type (got "int", expected "str")
thing.py:12: error: Argument 2 to "outer_inner" has incompatible type "None"; expected "str"

Yet while pyre does not find errors in the top level equivalent function outer_inner, it doesn't emit any errors about the nested function:

$ pyre check
 ƛ Found 1 type error!
thing.py:2:4 Incompatible return type [7]: Expected `str` but got `int`.
@dark
Copy link
Contributor

dark commented May 27, 2018

Hi @PeterJCLaw, thanks for the report.
We are aware of this limitation, and adding support to type-check nested functions is in our todo list.

@dark dark added the enhancement Improvements and feature requests label May 27, 2018
@PeterJCLaw
Copy link
Author

@dark Thanks! Is there a list of known limitations somewhere, to save us reporting (and you having to triage) known limitations?

@dark
Copy link
Contributor

dark commented May 28, 2018

Unfortunately we don't have such a list in the repo. We should add one.

@dark
Copy link
Contributor

dark commented Jul 26, 2018

This feature has been implemented a while ago, I had forgot to ping this task. The example above now triggers errors on all relevant lines.

@dark dark closed this as completed Jul 26, 2018
@PeterJCLaw
Copy link
Author

Nice, thanks for fixing 😊

facebook-github-bot pushed a commit that referenced this issue Jul 14, 2021
Summary:
Several fixes:
- one of the examples bothered me because the okay and bad
  case were not the same (3 vs 2 type variables) in a way that
  didn't highlight the point (don't repeat type variables)
- other than that, mostly trying to get consistent style:
  - 4 spaces, not 2 (unfortunately editors often do 2 by default
    on markdown, which is presumably why we keep getting 2-spaced
    python code)
  - always have a blank line between functions
  - make any typing imports explicit (this is debateable but most
    of our existing examples do it, so it's good to be consistent)
  - 2 spaces before comments

Reviewed By: grievejia

Differential Revision: D29690381

fbshipit-source-id: 47876f06d4ffa4a458d5fb22198ee91127c38ceb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvements and feature requests
Projects
None yet
Development

No branches or pull requests

2 participants