Struct GitlabCiFormatter 

pub struct GitlabCiFormatter { /* private fields */ }

Formatter for GitLab CI ecosystem LSP responses.

Implementations

impl GitlabCiFormatter

pub fn new( routes: Arc<DashMap<String, GitlabRoute>>, tag_index: Arc<DashMap<PackageName, Arc<TagIndex>>>, ) -> Self

Creates a new formatter over the given shared registry handles.

Trait Implementations

impl DiagnosticMessages for GitlabCiFormatter

fn yanked_message(&self) -> &'static str

Message for yanked/deprecated versions in diagnostics.

fn yanked_label(&self) -> &'static str

Label for yanked versions in hover.

fn deprecated_message(&self) -> &'static str

Message for a package-level deprecation/abandonment diagnostic (issue #205).

fn deprecated_label(&self) -> &'static str

Label for a deprecated package in hover.

impl DiagnosticPolicy for GitlabCiFormatter

fn strict_semver_prerelease_exclusion(&self) -> bool

Whether this ecosystem’s requirement/version syntax follows strict SemVer 2.0.0 pre-release semantics: a pre-release version (X.Y.Z-pre) is excluded from matching requirement unless requirement itself pins to the same X.Y.Z tuple with a pre-release tag — the rule Cargo’s semver crate and npm’s node-semver both implement, and that compile_requirement’s matcher inherits from its underlying comparator.

fn supports_package_rename(&self) -> bool

Whether this ecosystem’s deprecation payload (crate::Deprecation::replacement) is safe to offer as a “Replace with X” rename quickfix.

fn yanked_diagnostic_applies_to( &self, _dep: &dyn Dependency, _requirement: &VersionReq, ) -> bool

Whether the “requirement satisfiable only by a yanked version” diagnostic (crate::lsp_helpers::requirement_matches_only_yanked) should evaluate requirement at all for this ecosystem.

impl OsvNaming for GitlabCiFormatter

fn osv_version(&self, version: &str) -> String

Unprefixed — mirrors deps-github-actions’s identical rationale, kept for cross-ecosystem consistency even though it is largely unreachable here (a git-tag pin has no OSV coordinate by name).

fn osv_package_name(&self, dep: &dyn Dependency) -> Option<String>

OSV.dev’s canonical spelling for dep’s package name, or None if this dependency cannot be mapped (e.g. a non-GitHub Swift package).

fn osv_version_to_native(&self, version: &str) -> String

Converts a version string as it appears in an OSV advisory record (e.g. crate::osv::Advisory::fixed_versions) into this ecosystem’s own version namespace, as used in manifests and by the registry.

impl PackageNaming for GitlabCiFormatter

fn validate_package_name(&self, name: &str) -> Result<(), InvalidPackageName>

Accepts both the bare (org/proj[/comp]) and host-qualified (host/org/proj[/comp]) coordinate shapes — is_valid_gitlab_coordinate is a syntactic gate only, not a semantic classifier (see that function’s doc).

fn normalize_package_name(&self, name: &PackageName) -> String

Normalize package name for lookup (default: identity).

impl PackageRendering for GitlabCiFormatter

fn format_version_replacing_for( &self, dep: &dyn Dependency, version: &ConcreteVersion, current: &str, ) -> String

Preserves current’s v-prefix style for a normal (Sha/Tag/Branch/unpinned) update; Partial/Latest pins are returned unchanged — bumping 1.2 to 1.3.0 changes the pin’s kind, not just its value, so the shared no-op guard correctly suppresses the code action instead of writing a value-changing-but-kind-wrong edit.

fn suppress_package_url(&self, source: &DependencySource) -> bool

component: includes only (spec §8.2/NFR-004 carve-out) — a component’s name ends in the component segment, so https://{name} is not the project’s URL; the real project link is spliced into the hover body instead (crate::ecosystem’s generate_hover override). A project: include’s name is exactly {host}/{project_path}, so its standard heading link is correct and unsuppressed.

fn format_version_for_text_edit(&self, version: &ConcreteVersion) -> String

Format version string for code action text edit.

fn package_url(&self, name: &PackageName) -> String

Get package URL for hover markdown.

fn format_version_replacing( &self, version: &ConcreteVersion, _current: &str, ) -> String

Format version as a replacement for the existing requirement text current, preserving current’s operator/pin style where the ecosystem supports more than one.

fn is_position_on_dependency( &self, dep: &dyn Dependency, position: Position, ) -> bool

Detect if cursor position is on a dependency for code actions.

impl RequirementResolution for GitlabCiFormatter

fn requirement_is_unresolved(&self, requirement: &VersionReq) -> bool

Whether requirement’s pin — classified purely from its own text, mirroring crate::component::classify_component_pin_style’s shape-only rule — could not be resolved to a concrete version constraint: a SHA or branch-shaped ref.

Text-only, so ambiguous for a shape shared between grammars (#466 review M-c) — a caller that already has the dependency in hand should call Self::requirement_status_for instead, which consults its authoritative crate::types::PinStyle rather than re-guessing from text.

fn is_requirement_up_to_date( &self, requirement: &VersionReq, latest: &ConcreteVersion, ) -> bool

~latest is always up to date (it dynamically tracks the newest release, like an existence wildcard). A Partial pin (1.2, 1) is up to date while latest falls within its GitLab tilde-range semantics. A Tag pin is compared by normalized exact-string equality. A SHA/branch pin returns true unconditionally — never a false “outdated” (the diagnostic itself is separately gated by Self::requirement_is_unresolved; this is the boolean fallback for a caller that does not consult that first, e.g. the “Update N outdated” code lens).

Text-only, so ambiguous for a shape shared between grammars — see Self::requirement_status_for’s doc for the dependency-aware alternative a caller holding the dependency should prefer.

fn requirement_status_for( &self, dep: &dyn Dependency, requirement: &VersionReq, latest: &ConcreteVersion, ) -> RequirementStatus

#466 review M-c: consults dep’s own parse-time PinStyle (authoritative — set once, at parse time, from the correct project-vs-component grammar) instead of re-classifying requirement’s raw text, which is ambiguous between the two: "1.2" is PinStyle::Partial under the component: pin grammar (crate::component::classify_component_pin_style) but PinStyle::Branch under the simpler project: ref grammar (crate::parser’s classify_project_pin) — indistinguishable from the text alone. This is the same source of truth PackageRendering::format_version_replacing_for already consults, so the two can no longer disagree about the same dependency (previously: the outdated diagnostic text-reclassified a project: ref: "1.2" as Partial and silently suppressed itself, while the code action offered by format_version_replacing_for’s correct Branch classification still treated it as a normal, bumpable pin).

fn version_satisfies_requirement( &self, version: &ConcreteVersion, requirement: &str, ) -> bool

Check if a version satisfies a requirement string.

fn requirement_status( &self, requirement: &VersionReq, latest: &ConcreteVersion, ) -> RequirementStatus

Tri-state variant of is_requirement_up_to_date that distinguishes “confirmed up to date” from “could not be resolved, so we don’t know.”

fn compile_requirement( &self, _requirement: &VersionReq, ) -> Option<Box<dyn RequirementMatcher>>

Compiles requirement into a matcher for precise membership testing against a list of candidate version strings, or None when this ecosystem cannot parse or cannot model this requirement form — in which case no unsatisfiable-requirement diagnostic is produced for it.

fn requirement_is_undecidable_given_available( &self, _requirement: &VersionReq, _available: &[ConcreteVersion], ) -> bool

Whether this ecosystem’s registry can silently omit a published version from available in a way indistinguishable from “never published” — and, if so, whether requirement names a version-space region that specific omission could explain, given the versions actually observed in available.

fn manifest_requirement_is_resolved_version(&self, dep: &dyn Dependency) -> bool

Whether dep’s manifest version-requirement line is itself the exact version already selected — never a range.

impl SourcePolicy for GitlabCiFormatter

fn can_resolve_source(&self, source: &DependencySource) -> bool

Only a source this crate’s registry actually routes — mirrors every other per-source-routing ecosystem’s override (deps-npm, deps-pypi, deps-go, deps-nuget). Pure function of source; must never read live configuration (spec §4.5 — a live-reading predicate here would replace the correct FR-012 informational diagnostic with a false “Unknown package” the moment a config change flips it, while the background fetch it would then imply has not actually run).

fn source_is_public_registry_content(&self, source: &DependencySource) -> bool

Whether source’s content is exactly the default public registry’s — safe to treat as such for OSV vulnerability scanning, cache-key signature construction, and hover heading links.