-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[AST] NFC: Repack misc AnyFunctionType bits #13395
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
[AST] NFC: Repack misc AnyFunctionType bits #13395
Conversation
@@ -2397,7 +2399,6 @@ getSILFunctionLanguage(SILFunctionTypeRepresentation rep) { | |||
class AnyFunctionType : public TypeBase { | |||
const Type Input; |
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.
If we store the parameters directly why do we store the input type as well?
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.
That is a good question. I imagine that in practice that const Type Input
is effectively a cache. In any case, that is beyond the scope of this PR.
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.
Mea culpa: Haven't finished migrating clients away from the old representation. We shunt back and forth between the two still - would require more work than just one or two PRs to switch.
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.
So I've been poking around this area. @CodaFi – Where in your priority list is eliminating getInput()
?
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.
Somewhere at or below eliminating InOutType
. That's a much more feasible goal than re-formulating the way the type checker looks at paren types at the moment
@swift-ci please smoke test and merge |
AnyFunctionTypeBits.ExtInfo = Info.Bits; | ||
AnyFunctionTypeBits.NumParams = NumParams; |
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.
Can you add an assertion that this hasn't dropped information? (in case someone actually has 1024 parameters)
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.
Sure. I figured that about 1000 parameters was about 100 times more than any reasonable programmer would need/want. :-)
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.
Oh, for sure, but code generators aren't reasonable programmers. (Clearly I don't really care at this time, though, or I'd ask for something stronger than an assertion.)
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.
Ya, code generators are a pain. They can easily exceed otherwise reasonable compile time limits. That being said, I think adding runtime errors when compile time limits are exceeded is a separable goal.
@swift-ci please smoke test |
No description provided.