Xcode 11 beta 5 - no Swift declarations found

[johnfairh]

Opening this in advance of anyone else getting stuck:

Xcode has started using a response file to pass Swift file names to xcodebuild which leaves sourcekitten unable to figure out what files are in the module.

Workaround for now is to do jazzy -x USE_SWIFT_RESPONSE_FILE=NO.

The Xcode feature will probably stick around, was added due to CLI length overflows, so I think we'll have to teach sourcekitten how to read the response file.

[jpsim]

Thanks for the heads up!

[sdc-78]

The -x option does not seem to be processed when building doc from a podspec.

A workaround is to write USE_SWIFT_RESPONSE_FILE=NO in a file and make the XCODE_XCCONFIG_FILE environment variable point to this file when running jazzy.

[xrolfex]

Have you had any issues with this consistently running? It seems like most timesI run
jazzy -x USE_SWIFT_RESPONSE_FILE=NO --min-acl private --output ~/Desktop/output
I get 0% documentation coverage. Yet, sometimes I do get documentation generated. I am using Xcode 11 GM

Typical Output:

Running xcodebuild
Checking xcodebuild -showBuildSettings
Assuming New Build System is used.
0% documentation coverage with 0 undocumented symbols
building site
building search index
jam out ♪♫ to your fresh new docs in `../output`

Working Output:

[13:49:01]: ▸ Running xcodebuild
[13:49:27]: ▸ Parsing AppDelegate.swift (1/19)
[13:49:31]: ▸ Parsing SceneDelegate.swift (2/19)
[13:49:31]: ▸ Parsing BlockIdentified.swift (3/19)
[13:49:32]: ▸ Parsing ChartModels.swift (4/19)
[13:49:32]: ▸ Parsing Logic.swift (5/19)
[13:49:33]: ▸ Parsing MatrixBlock.swift (6/19)
[13:49:33]: ▸ Parsing FunctionalUtils.swift (7/19)
[13:49:34]: ▸ Parsing SwiftUIExtensions.swift (8/19)
[13:49:34]: ▸ Parsing UIKeyCommandHostingViewController.swift (9/19)
[13:49:36]: ▸ Parsing BlockView.swift (10/19)
[13:49:36]: ▸ Parsing BarChartView.swift (11/19)
[13:49:37]: ▸ Parsing BarsView.swift (12/19)
[13:49:38]: ▸ Parsing LabelsView.swift (13/19)
[13:49:38]: ▸ Parsing LegendView.swift (14/19)
[13:49:39]: ▸ Parsing ProgressShape.swift (15/19)
[13:49:40]: ▸ Parsing ProgressView.swift (16/19)
[13:49:40]: ▸ Parsing GameView.swift (17/19)
[13:49:42]: ▸ Parsing GridView.swift (18/19)
[13:49:42]: ▸ Parsing InsightsView.swift (19/19)
[13:49:43]: ▸ building site
[13:49:44]: ▸ building search index
[13:49:45]: ▸ 20% documentation coverage with 133 undocumented symbols
[13:49:45]: ▸ included 168 private, fileprivate, internal, public, or open symbols
[13:49:45]: ▸ jam out ♪♫ to your fresh new docs in `docs/jazzy`

[johnfairh]

@xrolfex I haven't seen this, but I think the difference in output means that in the first case no rebuild is happening (because up to date?) and sourcekitten is using something from DerivedData -- which doesn't have the special flag?

Could try adding clean,build to your -x flags -- might avoid the DerivedData cache hit.

[xrolfex]

@johnfairh Interesting, even with trying that I still end up with the same 0% message.

[johnfairh]

Closing this as fixed in jazzy 0.11 -- this includes sourcekitten 0.25.0 that understands the response file syntax. This should address the issues mentioned in this thread; if the 'unpredictable behavior' issue continues then we'll address that separately -- response file could be a red herring!

[sunshinejr]

Interestingly enough, I just happen to have the same issue with generating Moya docs using Xcode 11.3. Clean didn't help, so I had to remove derived data manually and then run the script with -x USE_SWIFT_RESPONSE_FILE=NO flag. So in our case we had to run these two steps to consistently get the output docs:

rm -rf ~/Library/Developer/Xcode/DerivedData/Moya*
jazzy -x USE_SWIFT_RESPONSE_FILE=NO -o _moya.github.io

[johnfairh]

@sunshinejr that probably means that xcodebuild fails when run in Moya's root directory -- there's a sourcekitten bug (linked above) that is hiding that from you; things go downhill from there. Looking at the update_docs_website.sh script it's trying to build straight from a clone so I guess dependencies are missing -- will be incomplete docs involving types/symbols from the dependencies.

We should probably start a new thread if you want to pursue this: your current workaround will fail when we fix the sourcekitten bug to actually tell you about the error.