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

Xcode 11 beta 2/3 fails to compile #15

Closed
ilyapuchka opened this issue Jul 7, 2019 · 6 comments · Fixed by #22
Closed

Xcode 11 beta 2/3 fails to compile #15

ilyapuchka opened this issue Jul 7, 2019 · 6 comments · Fixed by #22

Comments

@ilyapuchka
Copy link

ilyapuchka commented Jul 7, 2019

Trying to compile in Xcode 11 beta 2 result in the build error. It might be Xcode issue (and I haven't tried latest beta) but maybe you'll have an idea for a fix if it is not.

Build NonEmpty_2019-07-07T16-23-17.txt

UPD: same on beta 3

@ilyapuchka ilyapuchka changed the title Xcode 11 beta 2 fails to compile Xcode 11 beta 2/3 fails to compile Jul 7, 2019
@pteasima
Copy link

pteasima commented Jul 10, 2019

Same here, and also in stable Xcode.

Catalina beta3
Cocoapods 1.7.4
both Xcode11 beta 3 + 11commandlinetools and Xcode10.2.1 + 10.2.1commandlinetools

@loganmoseley
Copy link

loganmoseley commented Jul 16, 2019

I've had the same build error on Catalina and Xcode 11 beta 3, as well as Mojave and Xcode 10.2.1. I'd be happy to open a PR but I'm not sure where to start. My build error's very similar to @ilyapuchka's, only shorter. The most important lines of the error, it seems like, are

*** DESERIALIZATION FAILURE (please include this section in any bug report) ***
result not found
Cross-reference to module 'NonEmpty'
... NonEmpty
... in an extension in module 'NonEmpty'
... SubSequence

Stack dump:
[...]

1. While deserializing SIL function "$s8NonEmptyAAVyxGSMAASMRzrlSM6swapAtyy5IndexQz_AFtFTW"
2. While reading from 'NonEmpty'
3. While finishing conformance for protocol conformance to 'MutableCollection' (in module 'Swift') for type 'NonEmpty<C>'

This alludes to the problematic file being NonEmpty+MutableCollection.swift. If that file's removed from the target, the project builds. I haven't gotten results more granular than that.

NonEmpty build deserialization failure - Xcode11b3.txt

@loganmoseley
Copy link

Filed with the fruit company as FB6699142. I'll report back if I hear anything.

@ivopintodasilva
Copy link

This is happening to me on Xcode 11 stable release also 😞 Do you have any news on this?

p4checo added a commit to p4checo/swift-nonempty that referenced this issue Oct 10, 2019
For some unknown reason (at least to me) the `subscript(position:)`
extension on `MutableCollection` where `Index == Int` was causing the
swift compiler to crash with a weird `DESERIALIZATION FAILURE` error,
as mentioned on pointfreeco#15.

Updating the `subscript` to use `C.Index` instead of `Int` appears to
make the compiler happy and successfully compile the project. My
suspicion is that it somehow enables it to disambiguate between the
multiple `subscript` implementations, but it's pure speculation 🔮.

On our tests this seems to have fixed the issue, and since it's an
equivalent definition of the subscript (even though more "precise"
from a generic POV), it should cause no side effects.

Fixes pointfreeco#15. 🎉
p4checo added a commit to p4checo/swift-nonempty that referenced this issue Oct 10, 2019
For some unknown reason (at least to me) the `subscript(position:)`
extension on `MutableCollection` where `Index == Int` was causing the
compilation to fail with a weird `DESERIALIZATION FAILURE` error,
as mentioned on pointfreeco#15.

Updating the `subscript` to use `C.Index` instead of `Int` appears to
make the compiler happy and successfully compile the project. My
suspicion is that it somehow enables it to disambiguate between the
multiple `subscript` implementations, but it's pure speculation 🔮.

On our tests this seems to have fixed the issue, and since it's an
equivalent definition of the subscript (even though more "precise"
from a generics POV), it should cause no side effects.

Fixes pointfreeco#15. 🎉
@p4checo
Copy link
Contributor

p4checo commented Oct 10, 2019

Well, apparently I got a bit carried away on #22, and the "fix" only worked on incremental builds 😓, which is no different from the current version (which fails to compile on clean builds, but works the second time).

Sorry for the noise 😇

UPDATE: After much experimentation, I think I've found a fix that works even on clean builds. It consists of making NonEmpty conform to Collection right from the declaration, instead of in an extension. Not sure why this fixes it though 🤷‍♂

@p4checo
Copy link
Contributor

p4checo commented Oct 10, 2019

If this actually fixes the bug (as I hope), we should probably open/mirror the bug over at https://bugs.swift.org for better public visibility. We already have the "hardest" bit, which is a working PoC 😄.

@loganmoseley do you know if it has been mirrored already?

mbrandonw pushed a commit that referenced this issue Jan 30, 2020
* Fix compiler failure in Xcode 11

For some unknown reason (at least to me) the `subscript(position:)`
extension on `MutableCollection` where `Index == Int` was causing the
compilation to fail with a weird `DESERIALIZATION FAILURE` error,
as mentioned on #15.

Updating the `subscript` to use `C.Index` instead of `Int` appears to
make the compiler happy and successfully compile the project. My
suspicion is that it somehow enables it to disambiguate between the
multiple `subscript` implementations, but it's pure speculation 🔮.

On our tests this seems to have fixed the issue, and since it's an
equivalent definition of the subscript (even though more "precise"
from a generics POV), it should cause no side effects.

Fixes #15. 🎉

* Make `NonEmpty` conform to `Collection` in type declaration

Apparently by defining `NonEmpty` as conforming to `Collection` right
away in its declaration (instead of in an extension), the compilation
failure seems to be fixed.

Even when performing a clean build, the target now successfully
compiles. 🎉

Not sure about the actual cause for this, but this definitely seems
like a compiler bug (file ordering / dependency, perhaps?).
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 a pull request may close this issue.

5 participants