pub enum MethodCatalogError {
Duplicate {
receiver: TypePattern,
name: &'static str,
arity: usize,
},
ConflictingBound {
method: &'static str,
var: &'static str,
first: Bound,
second: Bound,
},
AmbiguousWithIterable {
receiver: TypePattern,
name: &'static str,
arity: usize,
},
AmbiguousIterablePair {
name: &'static str,
arity: usize,
},
IterableOutsideReceiver {
method: &'static str,
arity: usize,
},
}Expand description
Errors that can occur while building a MethodCatalog.
Variants§
Duplicate
Two entries share the same (receiver, name, arity) triple. Overloads
are not permitted; this is a build-time catalog bug.
ConflictingBound
One entry declares two different bounds for the same type variable. A bound is a fact about the variable, so the row is asking for two incompatible things and whichever the checker happened to read first would win silently.
AmbiguousWithIterable
A concrete-receiver row shares a (name, arity) with a generic
TypePattern::Iterable row, on a receiver the generic one accepts
(ADR-127 decision 1).
Both spellings would match at the call site, and the catalog’s key is
(receiver, name, arity) — so the two are not duplicates and nothing
would refuse them; whichever came first in insertion order would win.
That is a precedence rule, and a precedence rule is what makes “which
does this call resolve to” a question at all (decision 6). The check
scopes to PIPELINE_RECEIVERS
deliberately: a Grid[T].map/1 beside Iterable.map/1 is allowed,
because Grid is not one of the ten and §6.4 asks for that row by name.
AmbiguousIterablePair
Two generic TypePattern::Iterable rows share a (name, arity),
differing only in what they bound their item to (ADR-144).
This is AmbiguousWithIterable’s blind
spot — join for a sequence of Text beside join for a sequence of
Char. The pair is not a Duplicate, because the receivers differ; it
is not a shadowing, because neither row is the concrete one. But
praxis_hir::catalog::lookup matches an Iterable receiver on shape,
so both hit and inference takes the first — which is a precedence rule
by insertion order, exactly what ADR-127 decision 6 refuses. A sequence
of Char gets a differently-named row instead.
IterableOutsideReceiver
A row writes TypePattern::Iterable somewhere other than its receiver
(ADR-127 decision 1).
The receiver generalizes; two parameters must not. zip’s argument
is a Vec[U] and flat_map’s closure answers one, and the fused loop
indexes both with praxis_vec_len/praxis_vec_get directly — neither
has an IterPlan in scope, because neither is the source. Generalizing
either would put a SetPayload under praxis_vec_get, which is the
exact wrong-type read IterPlan exists to prevent. The pipeline
generalizes over what it walks, not over every sequence a row mentions.
The rule is also what makes the instantiation path total: an Iterable
names ten types, so pattern_to_type has no answer for one, and the
receiver is the one position that never asks it for an answer.
Trait Implementations§
Source§impl Clone for MethodCatalogError
impl Clone for MethodCatalogError
Source§fn clone(&self) -> MethodCatalogError
fn clone(&self) -> MethodCatalogError
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read moreSource§impl Debug for MethodCatalogError
impl Debug for MethodCatalogError
Source§impl Display for MethodCatalogError
impl Display for MethodCatalogError
impl Eq for MethodCatalogError
Source§impl Error for MethodCatalogError
impl Error for MethodCatalogError
1.30.0 · Source§fn source(&self) -> Option<&(dyn Error + 'static)>
fn source(&self) -> Option<&(dyn Error + 'static)>
1.0.0 · Source§fn description(&self) -> &str
fn description(&self) -> &str
use the Display impl or to_string()