fail to build Observable extenion method on RxSwift #67815
Labels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
overload resolution
Area → compiler → type checker: Overload resolution (ranking)
regression
type checker
Area → compiler: Semantic analysis
Comments
JCSooHwanCho
added
bug
18 tasks
|
FYI this is a regression from Xcode 15 Beta 5 where this worked with no issues |
|
CC: @xedin |
rudedogdhc
added a commit
to FountainheadMobileSolutions/RxSwiftExt
that referenced
this issue
Aug 9, 2023
Needed because Xcode 15beta6 has a conflict between RxSwift.Observable and Foundation.Observable. By using the static member names, swift is able to infer the correct type. See swiftlang/swift#67815 This may not be needed if Apple fixes the issue.
|
I was just having this problem too. Thanks for creating this issue! |
|
I will follow this, just jumped into this issue too |
|
Still an issue in Beta 7
|
|
Any chance we could get some clarity about this by anyone from the Core Team? The release date is right around the corner and this was already fixed and then regressed during the beta itself. @DougGregor |
|
Still an issue in Xcode 15 Beta 8 |
|
This is just unbelievable :( |
hborla
added
type checker
|
I believe this is a constraint system bug that was introduced by #66657, and this bug manifested with RxSwift when Foundation started exporting the Observation library in Xcode 15 Beta 6. The bug is specific to writing an explicitly specialized @xedin is working on a fix. |
xedin
added a commit
to xedin/swift
that referenced
this issue
Sep 1, 2023
Move logic from `ConstraintGenerator::visitOverloadedDeclRefExpr` to pre-check to avoid including macro declarations referenced without `#`. This means that pre-checking would synthesize `TypeExpr` in situations when there is a type reference that is shadowed by a stdlib macro. Resolves: swiftlang#67815 Resolves: rdar://114796811
|
Thank you so much for addressing this! I hope #68254 will bring us over this :) |
|
If you'd like you can test with https://ci.swift.org/job/swift-PR-toolchain-macos/850/artifact/branch-main/swift-PR-68254-850-osx.tar.gz |
xedin
added a commit
to xedin/swift
that referenced
this issue
Sep 1, 2023
Move logic from `ConstraintGenerator::visitOverloadedDeclRefExpr` to pre-check to avoid including macro declarations referenced without `#`. This means that pre-checking would synthesize `TypeExpr` in situations when there is a type reference that is shadowed by a stdlib macro. Resolves: swiftlang#67815 Resolves: rdar://114796811 (cherry picked from commit cf257aa)
Thanks Pavel! 
I'll try isolating the issue to a separate project but it would be nice to get our large project building as it would give high confidence the fix is good :) |
|
I've removed the Sentry SDK but now bumping into a different build issue, I'm just not 100% sure if it's just a side-effect of using a custom toolchain or there's something wrong. Attaching the dump just in case: |
|
I think this is worse opening is a separate issue, might be a bug on main that is only reproducible in assert builds. I am going to build a 5.9 toolchain, let’s see if it’s reproducible there as well. |
|
Ok, ping me when you have a 5.9 toolchain and I'll try again 🙏 thank you! |
|
Either FB or github issue works, I will post a toolchain link here. |
|
I'm getting relatively sporadic build failures (i.e. in different files every time) Seeing something like: I thought this is a non-assertion build? Do I have the right one?
|
|
All of our toolchain builds have assertions enabled, I am not sure what is going on because I managed to build 6.1.0 tag of the project locally with main and my changes. |
|
Maybe Xcode is not picking up a toolchain correctly in SwiftPM projects. Could you try using |
|
@xedin FYI this is still an issue in RC1 Check RxSwiftExt v6.1.0 (In 6.2.0 I added a typealias which helps but it's just a workaround and not a fix) |
|
Unfortunately, that is expected. The fix for this issue was only merged to |
|
Thanks Holly, |
|
The |
Thank you:) Sorry to go over my last question again but I truly don't understand the semantics🥲 Will a point release of 5.9.1 necessarily only come in the 15.1 version of Xcode itself? Or is there no way to tell? Thanks for the patience and pardon my ignorance on the topic :) |
|
I can only speak to Swift compiler versions. I cannot comment on Xcode releases. |
philfi
added a commit
to barkinglabs/RxBluetoothKit
that referenced
this issue
Sep 18, 2023
imports Foundation which causes issue described here: swiftlang/swift#67815 (comment)
philfi
added a commit
to barkinglabs/RxBluetoothKit
that referenced
this issue
Sep 18, 2023
imports Foundation which causes issue described here: swiftlang/swift#67815 (comment)
|
In my case, after updating RxSwiftExt to 6.2.1 the issue was gone |
Yup, we added a workaround, but it would be nice if the breakage wouldn't be happened from the get go Would be interesting to test after the next public release of Swift |
philfi
added a commit
to barkinglabs/RxBluetoothKit
that referenced
this issue
Sep 25, 2023
* Add RxSwift to remove ambiguity imports Foundation which causes issue described here: swiftlang/swift#67815 (comment) * Create contents.xcworkspacedata * Create Package.resolved
|
RxSwiftExt has added a workaround but RxRealm is not working unfortunately, so now we are waiting for the next release, until that xcode 14 it is :D |
socar-narr
added a commit
to socar-inc/RxBluetoothKit
that referenced
this issue
Oct 23, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
in Xcode 15 beta 6,RxSwiftExt Package is starting to fail building. It turns out that specific method declaration extension is problematic.
Steps to reproduce
I made a simple example to reproduce. or you can try to build RxSwiftExt Package.
but this two code is passing without error.
Expected behavior
build success without error
Environment
The text was updated successfully, but these errors were encountered: