Expand description
#2100 slice 4: generate a provider stub. For a capability declared in this
file that nothing in its context provides, the action scaffolds
provides Cap = CapImpl { … } right below the declaration, with every
operation’s signature copied and its body a typed default.
It is offered as a quick fix on bynk.exports.capability_not_provided
(an exported capability with no provider), and as a refactor with the
cursor on the capability’s name. The Workers-only
bynk.capability.not_provided is never raised in the editor, whose
analysis runs as the bundle target, so the refactor is what covers a
required capability.
The language has no placeholder expression, so a stub body must be a value
that type-checks (DECISION B re-checks the edit). Each body is a default of
the operation’s return type: the unrefined scalars, (), None, [], or
one of those inside an Effect. A capability with an operation returning
anything else (a record, a user sum, a Result) gets no action. So does a
derived capability, one declared outside a context, or one with generic
operations (whose type parameters the stub would have to repeat).
Whether a capability already has a provider is read from the committed
index’s implementation edges, so a provider in a sibling file counts. Like
fill-arms, the action is listed without an edit, and codeAction/resolve
computes and re-checks it. A bynk-fmt-canonical file is re-formatted and
the edit narrowed to the changed region.
Structs§
- Plan
- A planned stub: the capability, the provider’s name, and the edits.
- Request
- One capability the request points at, and how: through a “no provider” diagnostic (a quick fix) or its declaration’s name (a refactor).
- Target
- What a listed stub action’s
datanames.