Skip to content

[NFC] Decompose function input types #10264

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 1 commit into from
Jun 15, 2017

Conversation

CodaFi
Copy link
Contributor

@CodaFi CodaFi commented Jun 14, 2017

Prepares the AST for future work to eliminate getInput() and perform function type argument matching in a less ad-hoc manner.

@CodaFi CodaFi requested a review from DougGregor June 14, 2017 22:18
@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 14, 2017

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 5714bca
Test requested by - @CodaFi

@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 15, 2017

@swift-ci please test macOS platform

@swift-ci
Copy link
Contributor

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 5714bca
Test requested by - @CodaFi

@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 15, 2017

@swift-ci please test macOS platform

@swift-ci
Copy link
Contributor

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 5714bca
Test requested by - @CodaFi

@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 15, 2017

@swift-ci please test macOS platform

Identifier Label;

/// Whether the parameter has a default argument. Not valid for arguments.
bool HasDefaultArgument = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I commented on this on your other PR that builds on this... HasDefaultArgument really shouldn't be in the canonicalization. I don't think we can hoist CallArgParam up to the type system like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may need it for argument matching on overloads.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't belong in the type, though, and we don't want it to look like it has meaning there. I think CallArgParam needs to stay where it is, and we can introduce a AnyFunctionType::Param (or similar) that only captures what's actually in the type system.

@@ -2295,7 +2323,8 @@ getSILFunctionLanguage(SILFunctionTypeRepresentation rep) {
/// be 'thin', indicating that a function value has no capture context and can be
/// represented at the binary level as a single function pointer.
class AnyFunctionType : public TypeBase {
const Type Input;
const ArrayRef<CallArgParam> Input;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted before, we should use tail allocation to store the parameters and save ourselves the pointer/indirection.

Copy link
Contributor Author

@CodaFi CodaFi Jun 15, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

llvm::TrailingObjects requires this class be final.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you'd need to do the TrailingObjects thing on the subclasses

@swift-ci
Copy link
Contributor

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 5714bca
Test requested by - @CodaFi

@CodaFi CodaFi force-pushed the incohate-argumentarianism branch 4 times, most recently from 654bbe0 to 2085963 Compare June 15, 2017 18:28
@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 15, 2017

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 5714bca
Test requested by - @CodaFi

@swift-ci
Copy link
Contributor

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 5714bca
Test requested by - @CodaFi

@swift-ci
Copy link
Contributor

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 2085963213300191727cb1a00bfa92c962d57b5d
Test requested by - @CodaFi

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have minor comments, but this is looking great.

@@ -2501,22 +2534,35 @@ END_CAN_TYPE_WRAPPER(AnyFunctionType, Type)
///
/// For example:
/// let x : (Float, Int) -> Int
class FunctionType : public AnyFunctionType {
class alignas(AnyFunctionType::Param) FunctionType final :
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But... fixing the alignment of FunctionType doesn't help the trailing objects be properly aligned. You don't need this alignas change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for GenericFunctionType?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right.

private llvm::TrailingObjects<FunctionType, AnyFunctionType::Param> {
friend TrailingObjects;

unsigned NumParams;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this doesn't fit into AnyFunctionTypeBitfields, eh? ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Encode it in a pointer union and you've got a deal.

private llvm::TrailingObjects<GenericFunctionType, AnyFunctionType::Param> {
friend TrailingObjects;

unsigned NumParams;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sink NumParams down into AnyFunctionType?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@CodaFi CodaFi force-pushed the incohate-argumentarianism branch from 2085963 to 7ebdb27 Compare June 15, 2017 21:12
Prepares the AST for future work to eliminate `getInput()`
and perform function type argument matching in a less
ad-hoc manner.
@CodaFi CodaFi force-pushed the incohate-argumentarianism branch from 7ebdb27 to 0b5f442 Compare June 15, 2017 21:13
@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 15, 2017

@swift-ci please smoke test

@CodaFi
Copy link
Contributor Author

CodaFi commented Jun 15, 2017

⛵️

@CodaFi CodaFi merged commit d7f4238 into swiftlang:master Jun 15, 2017
@CodaFi CodaFi deleted the incohate-argumentarianism branch June 15, 2017 21:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants