Struct FragmentSupport 

pub struct FragmentSupport {
    pub ext: &'static str,
    pub scan: FragmentScanner,
}

What a step kind needs to own a fragment file format: the extension that identifies one and the parser that reads it. Source discovery asks the registry for the extension rather than naming a file type itself, so adding an engine never teaches the CLI a new one (ADR-0002).

Fields

ext: &'static str

File extension without the dot ("hurl").

scan: FragmentScanner

Reader for a whole file of that extension.

Implementations

impl FragmentSupport

pub fn claims(&self, name: &str) -> bool

Does name carry the extension this kind claims?

The one place the question is answered. It was answered in three: CLI discovery via Path::extension, the core scan via rsplit('.'), and the LSP’s corpus invalidation case-insensitively — so they disagreed about api.HURL (the editor rebuilt its corpus for a file nothing would ever scan) and about a dotfile named .hurl (a stem, not an extension, which only the rsplit spelling accepted).

Extension, not membership in a discovered set: a fragment file created while the editor is open is in no corpus yet, and it still has to invalidate the one being held.

Path semantics, so .hurl is a stem and not an extension — the same answer a user gets from every other tool that classifies files.

Trait Implementations

impl Clone for FragmentSupport

fn clone(&self) -> FragmentSupport

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Copy for FragmentSupport

impl Debug for FragmentSupport

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

Formats the value using the given formatter.