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

[SR-6736] Enforce 16-bit limit for # of function parameters, # of tuple type element #49285

Open
DougGregor opened this issue Jan 11, 2018 · 6 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself good first issue Good for newcomers

Comments

@DougGregor
Copy link
Member

Previous ID SR-6736
Radar None
Original Reporter @DougGregor
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, StarterBug
Assignee None
Priority Medium

md5: ea27fac0ee252473c9618a9257498092

Issue Description:

Swift's ABI uses 16 bits to store the number of parameter types in a function type and the number of element types in a tuple type. We should enforce these limits in the parser, so they don't slip through and become crashes at later phases.

@swift-ci
Copy link
Collaborator

Comment by Yasser Deceukelier (JIRA)

I might be interested in taking a look at this one.

But before I do: how are the number of arguments represented, unsigned binary (i.e. max 2^16 arguments), or is it signed? Are all the bits used to represent the number of arguments, or are some reserved?

@DougGregor
Copy link
Member Author

We have the full 16 bits stored as an unsigned value in the metadata.

@davezarzycki
Copy link
Collaborator

Personally speaking, 4 bits should be enough here. If you need more than 16 parameters or tuple elements, then you really should be using a `struct`. That being said, some people enjoy complexity and therefore 8 bits should conservatively split the difference between "reasonable" code and "unreasonable" code.

@swift-ci
Copy link
Collaborator

Comment by Yasser Deceukelier (JIRA)

Ok, got it.

I'm new to the swift compiler, so I might need to ask some additional questions.

Enforcing this limit, should it be done in the parser or can it happen as a check on the AST? (The latter sounds better in my opinion.) And if it could be done in the AST, which source file could I use as a reference/starting point to search where to add this feature?

@davezarzycki
Copy link
Collaborator

At the very least, start by auditing the various AST verifiers in lib/AST/ASTVerifier.cpp. From there, you should gain a good view on what data structures are involved. Next, you can work towards having Sema's type checking diagnose when too many parameters / tuple elements are seen.

Given various other goals, I doubt the AST will ever be optimized to the point where it cannot represent invalid code, therefore I don't think parsing will ever need to diagnose when limits (like the number of parameters) are exceeded.

@belkadan
Copy link
Contributor

Resetting assignee for all Starter Bugs last modified in 2018.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants