-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Temporarily disable target-based dependency resolution #2998
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
Temporarily disable target-based dependency resolution #2998
Conversation
We are seeing some issues with the full implementation of target-based dependency resolution done in swiftlang#2749 and need to temporarily disable it to unblock affected projects. The changes are still available behind a compile-time define `ENABLE_TARGET_BASED_DEPENDENCY_RESOLUTION` and the tests have been modified accordingly to work in both cases (some tests are skipped by default for now and only enabled when enabling target-based dependency resolution). I haven't yet distilled the issues into test cases, but once I have I'll start a branch of re-enabling this again.
@swift-ci please smoke test |
Ideally there would be a way to enable it dynamically, using a feature flag (I wonder why it wasn't behind a feature flag to begin with, actually). If that's a lot of code change then that might be a follow-on PR, but that seems that an approach that would allow testing to continue as the bugs are fixed. |
I cannot see the radar. May I ask what the issues are? |
@abertelrud I opted to not introduce a flag since this is hopefully a very temporarily change. If that ends up to not be the case, I'll convert it into a flag in a follow-on. |
@SDGGiesbrecht Sorry, I haven't been able to distill the issues down into examples I can share publicly at this point, as mentioned in the PR description. There's one example I can share, which is from the source-compatibility suite:
I'll share more examples as I have them. |
I’m not sure how to set it up to replicate that error. It won’t even load the manifest for me at the moment:
Looking back over the code, I’m going to take a wild guess and say that when I removed the filters from the pins in #2794 after the fact, this graph traversal possibly became invalid as something keyed by name, and needs special tailoring reminiscent of this other graph traversal. If that first traversal is faulty and capable of accidentally pruning part of the graph as it loads, I could imagine SwiftPM mistakenly concluding a pins file were at fault. But it is just a hunch. |
Okay, I figured out where the other errors were coming from:
Now that I have wasted so much time trying to fix a problem that isn’t a problem, I can move on to the real debugging... 🤦♂️ |
@neonichu, I solved it. It was a simple fix. I’ll submit a pull request in a few minutes when I clean up my commit history. |
I submitted #3006. |
We are seeing some issues with the full implementation of target-based dependency resolution done in swiftlang#2749 and need to temporarily disable it to unblock affected projects. The changes are still available behind a compile-time define `ENABLE_TARGET_BASED_DEPENDENCY_RESOLUTION` and the tests have been modified accordingly to work in both cases (some tests are skipped by default for now and only enabled when enabling target-based dependency resolution). I haven't yet distilled the issues into test cases, but once I have I'll start a branch of re-enabling this again.
We are seeing some issues with the full implementation of target-based dependency resolution done in #2749 and need to temporarily disable it to unblock affected projects. The changes are still available behind a compile-time define
ENABLE_TARGET_BASED_DEPENDENCY_RESOLUTION
and the tests have been modified accordingly to work in both cases (some tests are skipped by default for now and only enabled when enabling target-based dependency resolution).I haven't yet distilled the issues into test cases, but once I have I'll start a branch of re-enabling this again.
rdar://problem/65284674