1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
//! Compiler-dialect drivers for Cabin's build backend.
//!
//! Cabin's planner ([`cabin_build`](../cabin_build/index.html))
//! produces a *toolchain-independent* semantic IR - a list of
//! [`BuildAction`]s describing what to compile, archive, and link,
//! with no compiler flags spelled out. This crate is the single
//! boundary where that intent becomes a concrete command line.
//!
//! A [`Dialect`] names a compiler command-line family. Two are
//! supported:
//!
//! - [`Dialect::GnuLike`] - the GCC / Clang driver (`-std=c++17`,
//! `-O2`, `-D` / `-I` / `-isystem` / `-c` / `-o`, `-MD -MF`
//! depfiles).
//! - [`Dialect::Msvc`] - the Microsoft `cl.exe` / `lib.exe` driver
//! (`/std:c++17`, `/O2`, `/D` / `/I` / `/external:I` / `/c` /
//! `/Fo`, `/showIncludes` dependency tracking).
//!
//! The dialect owns every platform- and toolchain-specific
//! decision: how artifacts are named ([`Dialect::object_extension`],
//! [`Dialect::static_library_name`], [`Dialect::executable_name`]),
//! how Ninja discovers header dependencies ([`Dialect::ninja_deps`]),
//! and how each [`BuildAction`] is spelled ([`lower()`]). The planner
//! and the Ninja writer stay dialect-agnostic: they ask the dialect.
//!
//! This split mirrors the way LLVM's `clang` Driver constructs
//! per-toolchain jobs and the way `rustc` selects a `LinkerFlavor`:
//! one abstract description, many concrete spellings. Everything
//! here is pure, deterministic, and free of I/O, so both dialects
//! are fully unit-testable on any host.
pub use ;
pub use ;
pub use ;