@mmfl / @yxckjhasdkjh Right, I think we should file a bug here, would any of you mind filing one?
Here some stats: These are the number of files per module in the open-banking-connector project:
$ cd Sources && for f in *; do find "$f" -name '*.swift' | wc -l | tr -d '\n' && echo " $f"; done | sort -n
1 AccountTransactionTypes
1 PaymentInitiationTypes
3 AccountTransactionLocalTypes
3 BaseServices
3 PaymentInitiationLocalTypes
5 AccountTransactionTypeRequirements
7 PaymentInitiationTypeRequirements
40 OpenBankingConnector
116 PaymentInitiationApiV3p1p1Types
122 PaymentInitiationApiV3p1p2Types
143 AccountTransactionApiV3p0Types
199 AccountTransactionApiV3p1p1Types
277 AccountTransactionApiV3p1p2Types
So the largest module has 277 files. The total amount of files the Swift compiler as a whole seems to produce for this module is
$ find .build/x86_64-apple-macosx/debug/AccountTransactionApiV3p1p2Types.build/ -type f | wc -l
1388
which means it seems to produce roughly 5 output files per input file. So if it wants to open the input file as well as all the output files all in one go, it will need more than 1024 files... I would argue that is a bit excessive and we should look into options to reduce this, if the compiler team determine that this is impossible or too much work, then the compiler should still output at least an actionable error message telling you to raise ulimit -n to something high, it might even be able to give you an estimate given the number of source files.