It's also important to note that you'll have to form a full frontend command line since you'll be invoking the raw Swift compiler instead of the driver you may have been used to when building in the IDE for normal development. The frontend and driver have a non-overlapping understanding of all of the build flags, so it can be a little confusing at first to get things running.
Generally, you'll want to invoke
-frontend <action> <file>
<action> is a kind of
FrontendOptions::ActionType. So, to typecheck (and only typecheck) a file, you want
-frontend -typecheck /path/to/test.swift
Whereas compile a file to an object file, you want
-frontend -c /path/to/test.swift -o /path/to/output.o
If you want to see what real-world frontend command lines look like,
swiftc (the driver, not the frontend) inherited a driver flag from
-### which is an alias to
-driver-print-jobs. If you take a
swiftc command line and add
-### to the end of it, it'll show you a list of hypothetical frontend command lines it would have run on your behalf. This even works for subtools, so today when you go to launch the Swift LLDB REPL by typing
swift at the command line, you can see what's going on under the hood by invoking
swift -### instead:
$ swift -###
/Applications/Xcode-beta.app/Contents/Developer/usr/bin/lldb "--repl=-enable-objc-interop -sdk /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -color-diagnostics"
You can also see the command lines that get formed for builds in the IDE by selecting the build log in the organizer. If you expand the chevron to the right of a CompileSwift command, it'll show you the full frontend command line invoked to build that file/module. You can even tell the IDE to use a swiftc you built by setting the
SWIFT_EXEC build setting to point to your
swiftc. The command lines generated in the IDE from that custom compiler can be copied and pasted straight into the command line arguments field in Xcode for your compiler so you can debug a live build.