Struct PowerShellValidator 

pub struct PowerShellValidator;

Trait Implementations

impl SnippetValidator for PowerShellValidator

fn language(&self) -> Language

fn is_available(&self) -> bool

fn validate( &self, _snippet: &Snippet, _level: ValidationLevel, _timeout_secs: u64, ) -> Result<(SnippetStatus, Option<String>)>

Validate a snippet at the requested level.

fn max_level(&self) -> ValidationLevel

fn is_available_at(&self, _level: ValidationLevel) -> bool

fn validate_in_session( &self, snippet: &Snippet, level: ValidationLevel, timeout_secs: u64, session: Option<&ValidationSession>, ) -> Result<SnippetValidation>

fn validate_batch_in_session( &self, _snippets: &[&Snippet], _level: ValidationLevel, _timeout_secs: u64, _session: Option<&ValidationSession>, ) -> Option<Result<BatchValidation>>

fn achievable_level(&self, _requested: ValidationLevel) -> ValidationLevel

The highest level this run’s environment can actually reach for requested, as opposed to max_level’s fixed per-language ceiling. A validator whose deeper levels depend on a tool that may not be installed (a real type-checker, for instance) overrides this to report the level it can genuinely back up right now; the runner treats anything below requested as a real downgrade rather than a capability ceiling, because — unlike max_level — the limit could lift on a different machine. Default: no environmental limit beyond max_level. ~keep

fn achievable_level_is_structural(&self, _requested: ValidationLevel) -> bool

Whether the gap achievable_level reports for requested is structural — no check for that level is wired up in this validator at all, on any machine — as opposed to achievable_level’s default meaning of a real tool that merely happens to be missing from this run’s environment. The runner exempts a structural gap from Downgraded the same way it exempts max_level, because it is unsatisfiable however healthy the environment is; an environmental gap keeps its Downgraded status so a genuinely broken environment is never silently waved through. Default: environmental, not structural. ~keep

fn is_dependency_error(&self, _error_output: &str) -> bool

fn requires_session_exclusivity(&self) -> bool

Whether validate_batch_in_session is genuinely wired up to run one process for many snippets, as opposed to the default trait implementation, which always returns None and lets the runner fall back to one process per snippet. The runner uses this to decide upfront whether a group is a real batch — and should be logged and dispatched as one — or should skip the batch path entirely and go straight to the per-snippet fallback. Without this, every language was logged as Starting batched snippet validation regardless of batching support, and a validator that doesn’t support it silently fell through to a codepath that log line never covered, leaving no matching Finished event. That is purely an observability gap in the batch/fallback dispatch path, not a signal about whether the validator itself ran or hung — a healthy, fully-passing language is just as silent there as a broken one. ~keep Whether two snippets of this language may run concurrently within one validation session.

fn supports_batching(&self) -> bool

fn missing_session_artifacts( &self, _session: &ValidationSession, _level: ValidationLevel, ) -> Vec<PathBuf>

Build artifacts that must already be on disk before ANY snippet of this language can be validated in session at level – the files a alef build produces and a session’s manifest then points its toolchain at. A non-empty answer means every snippet claiming this session is unsatisfiable by construction, so the runner reports them once and spawns nothing (see runner::artifact_preflight).