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

Jump to bottom

[SR-11768] Stored property declaration + initialization expressions cannot be inlinable #54175

Closed
Lukasa opened this issue Nov 12, 2019 · 7 comments
Closed

[SR-11768] Stored property declaration + initialization expressions cannot be inlinable #54175

Lukasa opened this issue Nov 12, 2019 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself library evolution Feature: library evolution (umbrella feature for features that facilitate resilient libraries) performance

Comments

@Lukasa
Copy link
Contributor

Lukasa commented Nov 12, 2019

Previous ID SR-11768
Radar rdar://problem/57156728
Original Reporter @Lukasa
Type Bug
Status Resolved
Resolution Invalid
Environment

Apple Swift version 5.1.1 (swiftlang-1100.0.275.2 clang-1100.0.33.9)
Target: x86_64-apple-darwin19.0.0

Additional Detail from JIRA
Votes 1
Component/s Compiler
Labels Bug, LibraryEvolution, Performance
Assignee None
Priority Medium

md5: 93b4655140ea361188fad126d2aa580e

relates to:

  • SR-10931 Optional initialization inconsistent between Optional vs T?
  • SR-11777 'var something: 'Type?' always get double initialised

Issue Description:

Consider the following structure:

public struct Foo {
    @usableFromInline var x: Int
    @usableFromInline var y: Int = 0

    @inlinable
    public init(x: Int) {
        self.x = x
    }
}

When this initialiser is called from another module (like Foo(x: 1)) when compiled in release mode, the initializer generates the following code:

call       _$s3lib3FooV1ySivpfi         ; variable initialization expression of lib.Foo.y : Swift.Int
mov        qword [_$s4test1f3lib3FooVvp], 0x1 ; _$s4test1f3lib3FooVvp
mov        qword [qword_100004798], rax ; qword_100004798

This indicates that the initialization expression is actually a function. That function cannot be marked inlinable, which means for trivial initialization expressions like this one we incur the cost of a jump to the call site for this expression, even though it's a simple constant integer store.

I think the issue here is just that it needs to be possible to spell inlinability here.
@Lukasa
Copy link
Contributor Author

Lukasa commented Nov 12, 2019

See the NIO workaround: apple/swift-nio#1235

@beccadax
Copy link
Contributor

@slavapestov Do we use a function here for resilience, or is there another reason for this behavior?

@weissi
Copy link
Member

weissi commented Nov 13, 2019

@swift-ci create

@slavapestov
Copy link
Member

If you mark a struct as @Frozen, it will have inlinable initializers. Note that building with resilience off is almost like marking all structs as @Frozen and building with resilience on; however the behavior here is one exception. The reason is that marking initializers as inlinable is actually source breaking, since previously there was no rule about them only being allowed to reference public things.

So the compromise we settled on is that @Frozen enables the extra diagnostics that allow the initializer to be inlinable, even in non-resilient builds.

@slavapestov
Copy link
Member

I'm not sure if I should resolve this bug yet or not – if the above explanation doesn't make sense or I'm completely missing your original point, let me know. 🙂

@weissi
Copy link
Member

weissi commented Nov 18, 2019

Hey @slavapestov, ahh, got it. The problem is that SwiftNIO 2 support Swift 5.0 and requiring a higher Swift version would be SemVer major (ie. SwiftNIO 3.x) which would cause quite a disruption in the ecosystem. In Swift 5.0 however, @frozen is a syntax error.

@slavapestov
Copy link
Member

You can still use `@_fixed_layout` but it will generate a warning in 5.1.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself library evolution Feature: library evolution (umbrella feature for features that facilitate resilient libraries) performance
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@slavapestov @weissi @beccadax @Lukasa