Enforce 80-column limit on Graydon's changes. NFC

Author: jrose-apple

lib/Driver/DarwinToolChains.cpp

@@ -339,37 +339,43 @@ toolchains::Darwin::addArgsToLinkStdlib(ArgStringList &Arguments,
     Arguments.push_back(context.Args.MakeArgString(RuntimeLibPath));
 
     if (context.Args.hasArg(options::OPT_toolchain_stdlib_rpath)) {
-      // If the user has explicitly asked for a toolchain stdlib, we should provide one using
-      // -rpath. This used to be the default behaviour but it was considered annoying in at least
-      // the swiftpm scenario (see https://bugs.swift.org/browse/SR-1967) and is obsolete in all
-      // scenarios of deploying for swift-in-the-OS. We keep it here as an optional behaviour so
-      // that people downloading snapshot toolchains for testing new stdlibs will be able to link to
-      // the stdlib bundled in that toolchain.
+      // If the user has explicitly asked for a toolchain stdlib, we should
+      // provide one using -rpath. This used to be the default behaviour but it
+      // was considered annoying in at least the swiftpm scenario (see
+      // https://bugs.swift.org/browse/SR-1967) and is obsolete in all
+      // scenarios of deploying for swift-in-the-OS. We keep it here as an
+      // optional behaviour so that people downloading snapshot toolchains for
+      // testing new stdlibs will be able to link to the stdlib bundled in that
+      // toolchain.
       Arguments.push_back("-rpath");
       Arguments.push_back(context.Args.MakeArgString(RuntimeLibPath));
 
     } else if (tripleHasSwiftInTheOS(getTriple()) ||
                context.Args.hasArg(options::OPT_no_stdlib_rpath)) {
-      // If targeting an OS with Swift in /usr/lib/swift, the LC_ID_DYLIB install_name the stdlib
-      // will be an absolute path like /usr/lib/swift/libswiftCore.dylib, and we do not need to
-      // provide an rpath at all.
+      // If targeting an OS with Swift in /usr/lib/swift, the LC_ID_DYLIB
+      // install_name the stdlib will be an absolute path like
+      // /usr/lib/swift/libswiftCore.dylib, and we do not need to provide an
+      // rpath at all.
       //
-      // Also, if the user explicitly asks for no rpath entry, we assume they know what they're
-      // doing and do not add one here.
+      // Also, if the user explicitly asks for no rpath entry, we assume they
+      // know what they're doing and do not add one here.
     } else {
-      // The remaining cases are back-deploying (to OSs predating swift-in-the-OS). In these cases,
-      // the stdlib will be giving us (via stdlib/linker-support/magic-symbols-for-install-name.c)
-      // an LC_ID_DYLIB install_name that is rpath-relative, like @rpath/libswiftCore.dylib.
+      // The remaining cases are back-deploying (to OSs predating
+      // swift-in-the-OS). In these cases, the stdlib will be giving us (via
+      // stdlib/linker-support/magic-symbols-for-install-name.c) an LC_ID_DYLIB
+      // install_name that is rpath-relative, like @rpath/libswiftCore.dylib.
       //
-      // If we're linking an app bundle, it's possible there's an embedded stdlib in there, in which
-      // case we'd want to put @executable_path/../Frameworks in the rpath to find and prefer it,
-      // but (a) we don't know when we're linking an app bundle and (b) we probably _never_ will be
-      // because xcode links using clang, not the swift driver.
+      // If we're linking an app bundle, it's possible there's an embedded
+      // stdlib in there, in which case we'd want to put
+      // @executable_path/../Frameworks in the rpath to find and prefer it, but
+      // (a) we don't know when we're linking an app bundle and (b) we probably
+      // _never_ will be because xcode links using clang, not the swift driver.
       //
-      // So that leaves us with the case of linking a command-line app. These are only supported by
-      // installing a secondary package that puts some frozen swift-in-OS libraries in the
-      // /usr/lib/swift location. That's the best we can give for rpath, though it might fail at
-      // runtime if the support package isn't installed.
+      // So that leaves us with the case of linking a command-line app. These
+      // are only supported by installing a secondary package that puts some
+      // frozen swift-in-OS libraries in the usr/lib/swift location. That's the
+      // best we can give for rpath, though it might fail at runtime if the
+      // support package isn't installed.
       Arguments.push_back(context.Args.MakeArgString("/usr/lib/swift"));
     }
   }