Skip to content

Require @usableFromInline on associated type witnesses #20384

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 2 commits into from
Nov 9, 2018

Conversation

jrose-apple
Copy link
Contributor

...when the protocol and the conforming type are not both public but are both public-or-usableFromInline. It's possible to write inlinable functions that depend on these types:

public protocol HasAssoc {
  associatedtype Assoc
}
public func getAssoc<T: HasAssoc>(_: T) -> T.Assoc

@usableFromInline struct Impl: HasAssoc {
  @usableFromInline typealias Assoc = Int
}

@inlinable func test() {
  let x: Int = getAssoc(Impl())
}

rdar://problem/43824052

Inlinable code is permitted to rely on these associated types, so we
need to make sure their declarations are printed in the parseable
interface.

Part of rdar://problem/43824052
...when the protocol and the conforming type are not both public but
are both public-or-usableFromInline. It's possible to write inlinable
functions that depend on these types:

    public protocol HasAssoc {
      associatedtype Assoc
    }
    public func getAssoc<T: HasAssoc>(_: T) -> T.Assoc

    @usableFromInline struct Impl: HasAssoc {
      @usableFromInline typealias Assoc = Int
    }

    @inlinable func test() {
      let x: Int = getAssoc(Impl())
    }

rdar://problem/43824052
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test source compatibility

@jrose-apple
Copy link
Contributor Author

@swift-ci Please benchmark

Copy link
Member

@lorentey lorentey left a comment

Choose a reason for hiding this comment

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

Good catch!

@swift-ci
Copy link
Contributor

swift-ci commented Nov 7, 2018

Build comment file:

Performance: -Onone

TEST OLD NEW DELTA RATIO
Improvement
UTF8Decode_InitFromData_ascii 813 718 -11.7% 1.13x (?)

Code size: Swift libraries

TEST OLD NEW DELTA RATIO
Improvement
libswiftSwiftLang.dylib 81920 73728 -10.0% 1.11x
How to read the data The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test source compatibility

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.

5 participants