Steven Sheldon

If rust-lang/rfcs#1861 is accepted, we could fix this by making Object an opaque extern type.

The extern types RFC was accepted and implemented! Stabilization tracked in rust-lang/rust#43467.

Exploring some options here and created the [nul crate](https://github.com/SSheldon/nul). Currently conflicted on whether that's the best solution. I'm realizing that really, the only strings that need to be provided are...

The specialization RFC was accepted! Tracking issue: rust-lang/rust#31844

I've tested creating new schemes for watchOS targets in Xcode 14.0 beta 2 and 13.0, and it looks like in both cases Xcode uses `MacroExpansion` for buildable references for profile...

Sounds like this may be fixed in the beta 3 which came out yesterday: https://github.com/Swinject/Swinject/issues/511#issuecomment-1177109270 I haven't downloaded the new beta yet to verify that.

I don't believe this issue was fully fixed. In beta 4 (and also beta 3, based on a report from my colleague), it's true that the DVTAssertion is no longer...

A change like this does seem to fix my issue: ``` diff diff --git a/Sources/XcodeGenKit/SchemeGenerator.swift b/Sources/XcodeGenKit/SchemeGenerator.swift index 60922f2..db4062d 100644 --- a/Sources/XcodeGenKit/SchemeGenerator.swift +++ b/Sources/XcodeGenKit/SchemeGenerator.swift @@ -320,10 +320,11 @@ public class SchemeGenerator...

The snippet I posted is indeed not a good idea for non-framework targets. I found some similar logic for buildable product runnable vs macro expansion added in #328, and it...

I experienced an issue like this in another project and it was caused by the xcscheme. I believe this project has the same issue: https://github.com/Swinject/Swinject/blob/2.8.1/Swinject.xcodeproj/xcshareddata/xcschemes/Swinject-watchOS.xcscheme#L83 See yonaskolb/XcodeGen#1226 for more details...