-
-
Notifications
You must be signed in to change notification settings - Fork 3k
[mypyc] Generate introspection signatures for compiled functions #19307
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
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
92327e6
Generate introspection signatures for compiled functions
brianschubert 007e714
Fix signature generation for historical positional-only syntax
brianschubert 617d952
Add special method test
brianschubert a4094d0
Convert ternary to if statement as mypyc bug workaround
brianschubert f8689e9
Merge branch 'master' into mypyc-838-text-signatures
brianschubert 8e7b7cd
Generate introspection signatures for classes too
brianschubert d72482e
Expand unsupported default tests, minor tidy
brianschubert f035949
Merge branch 'master'
brianschubert File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Do you have any ideas about how to generalize this to support more kinds of default values? I guess we could special case empty lists and dictionaries, which are somewhat common (even if you are not supposed to use them as defaults), and perhaps named constants and enum values. What about using a placeholder default value for unsupported default values, such as
...
(ellipsis)?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.
Other defaults are loaded with
LoadStatic
ops, so we'd need to look at the module's__top_level__
IR to extract the values. That isn't too tricky to do (in fact I already have a rough patch that does that), but it could be expensive performance wise, since__top_level__
can be quite big and we'd be doing potentially many linear searches. Alternatively, we could try recording information about default arguments earlier on during IR building, though I haven't figured out a simple way to do that yetI actually tried that in a previous revision :-) I was worried that it might conflict with using an actual Ellipsis default argument at runtime. I'm also not sure what effect using a placeholder might have on the tools that consume these signatures. For example, I think stubtest might complain if a runtime signature had
...
as a default argument when the parameter isn't typed to actually acceptEllipsisType
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.
Recording information about default argument values during IR building seems like the most promising approach to me, though I'm not sure how easy this would be to implement. They could perhaps be stored in
FuncDecl
orFuncSignature
. I agree with you that analyzing__top_level__
seems too inefficient (and also inelegant).