Handling @overload with a docstring declaration
fixes #359. Added a check to make sure the body was not a docstring. Also added a test in the the third_party folder to show that the change is working. Let me know if anything needs to be changed.
Thanks!
The third_party/conformance tests are pulled from the typing spec conformance test suite, and shouldn't be modified directly here: https://github.com/python/typing/tree/main/conformance
For this type of feature, could you please add an integration test here? https://github.com/facebook/pyrefly/blob/main/pyrefly/lib/test/overload.rs
Also, I think we should only allow docstrings for function bodies if there is an @overload decorator
For example, a program like this should still be invalid:
def foo() -> int:
"""hello"""
Should be fixed. Added 3 test cases, first one is the basic one. Second one was to make sure that stuff after a docstring would still be typechecked properly and if the body of the function had more info, it wouldn't deem it a stub. The last one is for the case you mentioned of the nonoverloaded function with a docstring.
My commits are a bit messy because I am a little new to this but the code should be right
Also if you have others that you want me to fix, let me know! I am a bit swamped right now but I can try and get to it soon.
@yangdanny97 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.
Sorry for the delay @arnav-jain1 and thanks for your contribution
We'll get this merged soon!
My only feedback would be that it's more readable to just use a loop and set the is_overload/has_no_type_checking inside the loop v.s. using a reduce. I've applied that change to the patch that we're merging, so there's no action required from you.
@yangdanny97 merged this pull request in facebook/pyrefly@e888be05e61be13c96eeab456d19eca67fa3644c.
All good on the delay. Been a bit busy so I forgot. But yeah I'll remember that for the future. Im tryna learn haskell or functional programming in general and kind of used it as a fun exercise.
Im tryna learn haskell or functional programming in general and kind of used it as a fun exercise.
Functional programming is fun! Pyre being written in OCaml was one of the reasons I joined this team in the first place haha.
The simple reduce ops like sum/any/all are already their own functions, so it's pretty rare to actually use reduce directly I think. These days I only really use reduce if 1) it's chained after a map or filter 2) I'm reducing to a single value 3) the reduce operation is simple.