Unused import of `Foundation.URL` when OpenAPI spec does not contain a server URL

[ahoppen]

If the OpenAPI spec does not contain a server URL, the package does not compile without warnings anymore:

/private/var/folders/6g/w8x1jq613lxb8rywcsr6c2sr0000gn/T/tmp.kMsrdZjt6T/Test/.build/plugins/outputs/test/MyAPI/destination/OpenAPIGenerator/GeneratedSources/Types.swift:11:9: error: package import of 'Foundation' was not used in package declarations [#UnusedImportAccess]
 9 | package import struct Foundation.URL
10 | package import struct Foundation.Data
11 | package import struct Foundation.Date
   |         `- error: package import of 'Foundation' was not used in package declarations [#UnusedImportAccess]
12 | #endif
13 | /// A type that performs HTTP operations defined by the OpenAPI document.

Build the attached package with swift build -Xswiftc -warnings-as-errors to reproduce.

Test.zip

[simonjbeaumont]

Yep, good catch. We should probably fix that so that the generated code is warnings-clean. In the meantime, do the newer, more expressive warnings controls at the SwiftPM layer help as a workaround?

[ahoppen]

I have been able to work around this by just adding a stub server URL to openapi.yml.

[fp2s92d5pd-bit]

I reproduced #923 on main b2064e3 with Swift 6.3.3 and prepared a repository-native failing test. It covers a minimal types-only document, a no-server date-time document, and a server-only document. The latter two must retain package access to Foundation, so filtering solely on servers.isEmpty or URL usage appears unsafe.

Before implementing a production change, would you prefer import access to be derived from the generated declaration surface—leaving imports plain when the module is absent from package/public API—or a narrower document-derived rule? Would a failing-test-only PR be useful first?