Enum ValidationOutcome 

pub enum ValidationOutcome {
    Unsupported,
    Passed {
        tools_run: Vec<&'static str>,
        tools_missing: Vec<&'static str>,
    },
    Failed {
        tools_run: Vec<&'static str>,
        tools_missing: Vec<&'static str>,
        errors: Vec<String>,
    },
}

A validation result for one backend’s generated output, shaped for a caller (the CLI, in particular) to report directly to a user rather than for a test assertion to pick apart.

Three variants, not two, on purpose: collapsing Self::Unsupported into Self::Passed is the exact dishonesty ToolValidation exists to prevent – see that type’s doc comment. A caller that only distinguished pass from fail would report “OK” for a csharp-npgsql file that no compiler ever looked at, which is the bug this whole module was written to close.

Variants

Unsupported

No tool-based validator exists for this backend’s language at all (see ToolValidation::Unsupported). Not a pass and not a failure – report it as “not checked”, never as “checked, no problems”.

Passed

A validator exists and every checker that ran found nothing wrong.

tools_run names the checkers that actually inspected the code; tools_missing names any this validator would also have liked to run but could not find on PATH. Both are carried through rather than collapsed, because “passed, nothing was installed to check it” (tools_run empty) and “passed, poly verified it” are different claims a caller may want to report differently even though neither is a build failure under the default, non-strict policy this is built on (see ToolValidation::into_result_with_strictness).

Fields

tools_run: Vec<&'static str>

Checkers that ran to completion and found nothing wrong.

tools_missing: Vec<&'static str>

Checkers this validator wanted to run but could not find.

Failed

A checker found a problem with the generated code, or the harness itself could not drive an installed tool. Never produced by a merely-missing tool – see ToolOutcome::Missing vs. ToolOutcome::Failed, which is exactly the distinction that keeps an uninstalled linter from reading as a build failure here.

Fields

tools_run: Vec<&'static str>

Checkers that ran to completion (regardless of whether they were the one that reported a problem).

tools_missing: Vec<&'static str>

Checkers this validator wanted to run but could not find.

errors: Vec<String>

Findings, already prefixed with the tool name that reported each one – see ToolValidation::errors.

Implementations

impl ValidationOutcome

pub fn is_failure(&self) -> bool

Whether this outcome should stop a build: true only for Self::Failed.

Both Self::Unsupported and Self::Passed are “let it through” outcomes under the default policy – a caller that wants “no validator for this language” to also block a build (unusual: it would stop every C#, Rust, kotlin-exposed, and kotlin-r2dbc backend from ever generating) must match on the variant itself rather than use this helper.

Trait Implementations

impl Clone for ValidationOutcome

fn clone(&self) -> ValidationOutcome

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ValidationOutcome

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for ValidationOutcome

impl PartialEq for ValidationOutcome

fn eq(&self, other: &ValidationOutcome) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for ValidationOutcome