Files
swift-mirror/include/swift/Basic/SupplementaryOutputPaths.def
Ryan Mansfield ba0ce8aea6 Add frontend options to write SIL and LLVM IR as additional compilation output.
This commit adds -sil-output-path and -ir-output-path frontend options that
allow generating SIL and LLVM IR files as supplementary outputs during normal
compilation.

These options can be useful for debugging and analysis tools
workflows that need access to intermediate compilation artifacts
without requiring separate compiler invocations.

Expected behaviour:

Primary File mode:
 - SIL: Generates one .sil file per source file
 - IR: Generates one .ll file per source file

Single-threaded WMO mode:
 - SIL: Generates one .sil file for the entire module
 - IR: Generates one .ll file for the entire module

Multi-threaded WMO mode:
 - SIL: Generates one .sil file for the entire module
 - IR: Generates separate .ll files per source file

File Maps with WMO:
 - Both SIL and IR outputs using first entry's naming, which is
   consistent with the behaviour of other supplementary outputs.

rdar://160297898
2025-10-06 15:45:49 -04:00

175 lines
6.8 KiB
C++

//===--- SupplementaryOutputPaths.def - Output Names and Types --*- C++ -*-===//
//
// This source file is part of the Swift.org open source project
//
// Copyright (c) 2014 - 2017 Apple Inc. and the Swift project authors
// Licensed under Apache License v2.0 with Runtime Library Exception
//
// See https://swift.org/LICENSE.txt for license information
// See https://swift.org/CONTRIBUTORS.txt for the list of Swift project authors
//
//===----------------------------------------------------------------------===//
//
// This file defines all the Supplemtary Output Path variables and their
// output types.
//
//===----------------------------------------------------------------------===//
/// The path to which we should emit a header file that exposes the Swift
/// declarations to C, Objective-C and C++ clients for the module.
///
/// Currently only makes sense when the compiler has whole module knowledge.
/// The modes for which it makes sense incuide both WMO and the "merge
/// modules" job that happens after the normal compilation jobs. That's where
/// the header is emitted in single-file mode, since it needs whole-module
/// information.
///
/// \sa swift::printAsClangHeader
OUTPUT(ClangHeaderOutputPath, TY_ClangHeader)
/// The path to which we should emit a serialized module.
/// It is valid whenever there are any inputs.
///
/// This binary format is used to describe the interface of a module when
/// imported by client source code. The swiftmodule format is described in
/// docs/Serialization.md.
///
/// \sa swift::serialize
OUTPUT(ModuleOutputPath, TY_SwiftModuleFile)
/// The path to which we should emit a module source information file.
/// It is valid whenever there are any inputs.
///
/// This binary format stores source locations and other information about the
/// declarations in a module.
///
/// \sa swift::serialize
OUTPUT(ModuleSourceInfoOutputPath, TY_SwiftSourceInfoFile)
/// The path to which we should emit a module documentation file.
/// It is valid whenever there are any inputs.
///
/// This binary format stores doc comments and other information about the
/// declarations in a module.
///
/// \sa swift::serialize
OUTPUT(ModuleDocOutputPath, TY_SwiftModuleDocFile)
/// The path to which we should output a Make-style dependencies file.
/// It is valid whenever there are any inputs.
///
/// Swift's compilation model means that Make-style dependencies aren't
/// well-suited to model fine-grained dependencies. See docs/Driver.md for
/// more information.
///
/// \sa ReferenceDependenciesFilePath
OUTPUT(DependenciesFilePath, TY_Dependencies)
/// The path to which we should output a Swift "reference dependencies" file.
/// It is valid whenever there are any inputs.
///
/// "Reference dependencies" track dependencies on a more fine-grained level
/// than just "this file depends on that file". With Swift's "implicit
/// visibility" within a module, that becomes very important for any sort of
/// incremental build. These files are consumed by the Swift driver to decide
/// whether a source file needs to be recompiled during a build. See
/// docs/DependencyAnalysis.md for more information.
///
/// \sa swift::emitReferenceDependencies
/// \sa DependencyGraph
OUTPUT(ReferenceDependenciesFilePath, TY_SwiftDeps)
/// Path to a file which should contain serialized diagnostics for this
/// frontend invocation.
///
/// This uses the same serialized diagnostics format as Clang, for tools that
/// want machine-parseable diagnostics. There's a bit more information on
/// how clients might use this in docs/Driver.md.
///
/// \sa swift::serialized_diagnostics::createConsumer
OUTPUT(SerializedDiagnosticsPath, TY_SerializedDiagnostics)
/// The path to which we should output fix-its as source edits.
///
/// This is a JSON-based format that is used by the migrator, but is not
/// really vetted for anything else.
///
/// \sa swift::writeEditsInJson
OUTPUT(FixItsOutputPath, TY_SwiftFixIt)
/// The path to which we should output a loaded module trace file.
/// It is valid whenever there are any inputs.
///
/// The file is appended to, and consists of line-delimited JSON objects,
/// where each line is of the form `{ "name": NAME, "target": TARGET,
/// "swiftmodules": [PATH, PATH, ...] }`, representing the (real-path) PATHs
/// to each .swiftmodule that was loaded while building module NAME for target
/// TARGET. This format is subject to arbitrary change, however.
OUTPUT(LoadedModuleTracePath, TY_ModuleTrace)
OUTPUT(FineModuleTracePath, TY_FineModuleTrace)
/// The path to which we should output a TBD file.
///
/// "TBD" stands for "text-based dylib". It's a YAML-based format that
/// describes the public ABI of a library, which clients can link against
/// without having an actual dynamic library binary.
///
/// Only makes sense when the compiler has whole-module knowledge.
///
/// \sa swift::writeTBDFile
OUTPUT(TBDPath, TY_TBD)
/// The path to which we should emit a module interface, which can
/// be used by a client source file to import this module.
///
/// This format is similar to the binary format used for #ModuleOutputPath,
/// but is intended to be stable across compiler versions.
///
/// Currently only makes sense when the compiler has whole-module knowledge.
///
/// \sa swift::emitSwiftInterface
OUTPUT(ModuleInterfaceOutputPath, TY_SwiftModuleInterfaceFile)
/// The path to which we should emit a private module interface.
///
/// The private module interface contains all SPI decls and attributes.
///
/// \sa ModuleInterfaceOutputPath
OUTPUT(PrivateModuleInterfaceOutputPath,
TY_PrivateSwiftModuleInterfaceFile)
/// The path to which we should emit a package module interface.
///
/// The package interface contains package decls, SPIs, and public/inlinable decls.
///
/// \sa ModuleInterfaceOutputPath
OUTPUT(PackageModuleInterfaceOutputPath,
TY_PackageSwiftModuleInterfaceFile)
/// The path to which we should emit module summary file.
OUTPUT(ModuleSummaryOutputPath, TY_SwiftModuleSummaryFile)
/// The output path to generate ABI baseline.
OUTPUT(ABIDescriptorOutputPath, TY_SwiftABIDescriptor)
/// The output path to the module's API description.
OUTPUT(APIDescriptorOutputPath, TY_SwiftAPIDescriptor)
/// The output path for extracted compile-time-known value information
OUTPUT(ConstValuesOutputPath, TY_ConstValues)
/// The output path of Swift semantic info for this module.
OUTPUT(ModuleSemanticInfoOutputPath, TY_ModuleSemanticInfo)
/// The output path for YAML optimization record file.
OUTPUT(YAMLOptRecordPath, TY_YAMLOptRecord)
/// The output path for bitstream optimization record file.
OUTPUT(BitstreamOptRecordPath, TY_BitstreamOptRecord)
/// The output path to which we should output SIL as extra compilation output.
OUTPUT(SILOutputPath, TY_SIL)
/// The output path to which we should output LLVM IR as extra compilation output.
OUTPUT(LLVMIROutputPath, TY_LLVM_IR)