Handle -version argument

[cltnschlosser]

Currently we have the following for getting the compiler version. The issue with this is that I'm getting into a state where getToolPath(.swiftCompiler) is /tmp/swift my symlink to my swift-driver. This is causing an infinite loop because swiftCompilerVersion is called from Driver.init.

public func swiftCompilerVersion() throws -> String {
    try Process.checkNonZeroExit(
      args: getToolPath(.swiftCompiler).pathString, "-version",
      environment: env
    ).split(separator: "\n").first.map(String.init) ?? ""
  }

So taking a step back:
Should getToolPath(.swiftCompiler) ever point to my symlink?
If no, what am I doing wrong (was following the README).
If yes, then the implementation needs to change, the code below is in Basic/Version.cpp. Are these constants something we could have access to when building the driver? Does it even make sense for the driver to know about all these versions?

std::string getSwiftFullVersion(Version effectiveVersion) {
  std::string buf;
  llvm::raw_string_ostream OS(buf);

#ifdef SWIFT_VENDOR
  OS << SWIFT_VENDOR " ";
#endif

  OS << "Swift version " SWIFT_VERSION_STRING;
#ifndef SWIFT_COMPILER_VERSION
  OS << "-dev";
#endif

  if (!(effectiveVersion == Version::getCurrentLanguageVersion())) {
    OS << " effective-" << effectiveVersion;
  }

#if defined(SWIFT_COMPILER_VERSION)
  OS << " (swiftlang-" SWIFT_COMPILER_VERSION;
#if defined(CLANG_COMPILER_VERSION)
  OS << " clang-" CLANG_COMPILER_VERSION;
#endif
  OS << ")";
#elif defined(LLVM_REVISION) || defined(CLANG_REVISION) || \
      defined(SWIFT_REVISION)
  OS << " (";
  printFullRevisionString(OS);
  OS << ")";
#endif

  // Suppress unused function warning
  (void)&printFullRevisionString;

  return OS.str();
}

[cltnschlosser]

@DougGregor ran into this issue when trying to use swift-driver with MovieSwiftUI

[DougGregor]

Hmm. I think this issue with the symlinks was introduced via #25, where we reworked how tools are found, and I'm seeing it here, too. There are a few solutions:

• As a short-term hack, delete your swift symlink: Xcode will point at your swiftc symlink, but the driver is looking for swift so it will go find the real Swift compiler.
• The -driver-use-frontend-path option lets you specify exactly which Swift compiler to use. However, it's broken! I'm fixing it via Respect -driver-use-frontend-path throughout job creation #50
• At some point, I'll land [CMake] Make swift-frontend the primary Swift binary. swift#28003 to make the Swift frontend (the real compiler) named swift-frontend, so we'll look for that. Then swift and swiftc are reserved for the driver, whether it's the old one or the new one.

[cltnschlosser]

@DougGregor Using -driver-use-frontend-path I was able to verify that this works like the cpp driver. This forwards the version check to the compiler. (I think technically this is handled in the cpp driver and not the compiler, but it's using versions that are unique to the compiler).

[DougGregor]

This is basically in line with what we're doing today, but it reminds me that we shouldn't probably virtualize standard output / standard error for library clients. Constructing a Driver instance that happens to print help or version information shouldn't pollute the clients standard output / standard error: they should be able to capture that output themselves. Similarly, I could imagine clients wanting to handle process execution themselves rather than having the Driver initializer directly invoking processes. (Again, for another PR. This follows the precedent already established)

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test