Open stuhood opened 1 year ago
Have updated the TODO list in the description with some of the (unordered) next steps. In particular: we are not yet actually using the facility introduced by #19755 to drive solving when the syntax from #19797 is used.
I've updated the description to include two new tasks:
@rule
function names that we see are widely used in plugins/our-backends to ensure that they are self-explanatory, and renaming @rule
functions that are intended to be private..@sureshjoshi took a huge step on this one via #20572. Huzzah!
I've updated the description.
Added #21065 to the todo list.
(as motivated in #18905)
Implementation:
rule_graph
crate changes:Get
(DependencyKey
) for rule-graph solving to accept a fixed name/identifier for the rule to use, and some/all of its positional argumentsAwaitableCollector
) to support extracting directly called@rules
, in addition to the existing support for "rule helpers"implicitly(..)
builtin, which takes arguments similar toGet(TypeName, ..)
@rule
callsMultiGet
syntax@union
-usage syntax (or keep it type driven)@rule
decorator such that when it has been called directly (i.e., not called with some secret-handshake), it trampolines back out to fill the additional positional arguments and to begin memoizationasync def
anddef
@rules
, since the act of memoizing can potentially mean blocking to wait for a result computed by another task@rule
ids introduced in #19755 to drive@rule
solvingpants
-builtin goal which will execute a rewrite of one or more specified plugins or files fromawait Get(TypeName, ..)
->await rule_name(.., **implicitly(..))
@rule
to use at eachGet
callsite), so the rewritten file must actually have been loaded@rule
names that are widely used in plugins/in-repo-backends in cases where they are not sufficiently descriptive.