There are lots of other places we'll need to update as well. Take a look at Languages.ts and see all the things it interacts with. It might be sufficient to only add swift as a new enum value. Not sure.

And, it's probably going to be necessary to add the CODEQL_ENABLE_EXPERIMENTAL_FEATURES_SWIFT var to the environment for swift extraction.

At some point (now is probably too early), we're going to want an integration test for swift. Someone on our team can help with that.

Thanks for the comments, Andrew! I should have written what my goal with this PR was: We'd like to get Swift support on DCA as soon as possible so that we can monitor extractor and QL performance. If we could get this PR merged onto main it would mean that we didn't have to run DCA on a custom checkout of codeql-action.

There are lots of other places we'll need to update as well. Take a look at Languages.ts and see all the things it interacts with. It might be sufficient to only add swift as a new enum value. Not sure.

It was enough to get past the "Unsupported language: Swift" error I was getting when trying to get DCA working for Swift. Here's a run that shows that it working: https://github.com/dsp-testing/codeql-dca-worker/actions/runs/2414815040.

And, it's probably going to be necessary to add the CODEQL_ENABLE_EXPERIMENTAL_FEATURES_SWIFT var to the environment for swift extraction.

Yes, definitely. For now, we're injecting the --internal-use-lua-tracing flag onto codeql database init from DCA, and it sounds like this will be turned on for all of DCA next week. So I didn't include it in this PR to keep it as small as possible.

If you're concerned about this PR not being "complete" before we merge it we can make this PR a draft and continue to use its SHA as a custom checkout for DCA.