Module plugin_loading 

Runtime plugins: native libraries and WASM modules loaded from a path.

Both loaders decode a plugin’s self-description into one PluginAbi and wrap it in a RuntimePlugin, an ordinary Plugin that ExtensionRegistry::add_plugin accepts like any other: the same name rules, the same conflict checks.

A runtime plugin exchanges text only (see rich_plugin_api::abi), and everything it returns is sanitized here before a console sees it: terminal controls are made visible, and only a fence-ansi capability keeps SGR styling, through sanitize_ansi_for_decoder.

Loading is behind Cargo features, both off by default: dylib-plugins (load_native) and wasm-plugins (load_wasm). A native plugin runs arbitrary code in this process, so load one only from a path the user chose. See docs/design/plugin-loading.md and the threat model in docs/PLUGINS.md.

Structs

LoadOptions

Options for load.

RuntimePlugin

A loaded runtime plugin: its description, where it came from, and the backend that runs it. Keeping any of its capabilities keeps the backend (and a native library) loaded.

WasmLimits

Limits for a WASM plugin. Every call runs in a fresh instance.

Enums

LoadError

Why a runtime plugin could not be loaded. Every variant names the path.

RuntimeKind

How a runtime plugin was loaded.

Constants

MAX_OUTPUT_BYTES

The most bytes one call may return; more is an error.

MAX_SPANS

The most spans one highlighter call may return; the rest are dropped.

Traits

AbiBackend

Runs a runtime plugin’s capabilities. The native and WASM loaders each implement it; tests can too.

Functions

load

Load the plugin at path, choosing the loader by its extension.

load_native

Load a native plugin (.so, .dylib, .dll).

load_wasm

Load a WASM plugin with these limits.

load_wasm_bytes

load_wasm for a module already in memory: path is only where the plugin says it came from (its RuntimePlugin::path and the path in a LoadError). A host that checked the bytes first (against a lockfile, say) loads those bytes, not the file again.