Deal with remaining TODO(now) / TODO(soon).

c++/src/capnp/capability.h

@@ -159,7 +159,7 @@ public:
   // where no calls are being made.  There is no reason to wait for this before making calls; if
   // the capability does not resolve, the call results will propagate the error.
 
-  // TODO(soon):  method(s) for Join
+  // TODO(someday):  method(s) for Join
 
 protected:
   Client() = default;
@@ -279,7 +279,7 @@ public:
   // is no longer needed.  `context` may be used to allocate the output struct and deal with
   // cancellation.
 
-  // TODO(soon):  Method which can optionally be overridden to implement Join when the object is
+  // TODO(someday):  Method which can optionally be overridden to implement Join when the object is
   //   a proxy.
 
 protected:

c++/src/capnp/generated-header-support.h

@@ -135,7 +135,7 @@ inline kj::StringTree structString(StructReader reader) {
   return structString(reader, rawSchema<T>());
 }
 
-// TODO(soon):  Unify ConstStruct and ConstList.
+// TODO(cleanup):  Unify ConstStruct and ConstList.
 template <typename T>
 class ConstStruct {
 public:

c++/src/capnp/rpc.c++

@@ -63,7 +63,6 @@ kj::Maybe<kj::Array<PipelineOp>> toPipelineOps(List<rpc::PromisedAnswer::Op>::Re
         op.pointerIndex = opReader.getGetPointerField();
         break;
       default:
-        // TODO(soon):  Handle better?
         KJ_FAIL_REQUIRE("Unsupported pipeline op.", (uint)opReader.which()) {
           return nullptr;
         }
@@ -1261,8 +1260,10 @@ private:
           // message was received.  In this case, the original import ID will already have been
           // dropped and could even have been reused for another capability.  Luckily, the
           // resolution chain holds the capability we actually want.
-          KJ_IF_MAYBE(resolution, resolutionChain.findImport(importId)) {
-            return resolution->addRef();
+          if (descriptor.which() == rpc::CapDescriptor::SENDER_PROMISE) {
+            KJ_IF_MAYBE(resolution, resolutionChain.findImport(importId)) {
+              return resolution->addRef();
+            }
           }
 
           // No recent resolutions.  Check the import table then.
@@ -1289,9 +1290,6 @@ private:
 
           kj::Own<RpcClient> result;
           if (descriptor.which() == rpc::CapDescriptor::SENDER_PROMISE) {
-            // TODO(now):  Check for pending `Resolve` messages replacing this import ID, and if
-            //   one exists, use that client instead.
-
             auto paf = kj::newPromiseAndFulfiller<kj::Own<ClientHook>>();
             import.promiseFulfiller = kj::mv(paf.fulfiller);
             paf.promise = paf.promise.attach(kj::addRef(*importClient));
@@ -2334,7 +2332,6 @@ private:
       answer.pipeline = kj::mv(promiseAndPipeline.pipeline);
 
       if (redirectResults) {
-        // TODO(now):  Handle exceptions, dummy.
         auto resultsPromise = promiseAndPipeline.promise.then(
             kj::mvCapture(context, [](kj::Own<RpcCallContext>&& context) {
               return context->consumeRedirectedResponse();

c++/src/capnp/rpc.capnp

@@ -397,9 +397,9 @@ struct Finish {
   #    to support premature cancellation -- instead, the implementation may wait until the call
   #    actually completes and send a normal `Return` message.
   #
-  # TODO(soon):  Should we separate (1) and (2)?  It would be possible and useful to notify the
+  # TODO(someday):  Should we separate (1) and (2)?  It would be possible and useful to notify the
   #   server that it doesn't need to keep around the response to service pipeline requests even
-  #   though the caller hasn't yet finished processing the response.
+  #   though the caller still wants to receive it / hasn't yet finished processing it.
 
   questionId @0 :QuestionId;
   # ID of the call whose result is to be released.
@@ -780,11 +780,11 @@ struct Join {
   # A part of the join key.  These combine to form the complete join key which is used to establish
   # a direct connection.
 
-  # TODO(now):  Change this so that multiple parts can be sent in a single Join message, so that
-  # if multiple join parts are going to cross the same connection they can be sent together, so that
-  # the receive can potentially optimize its handling of them.  In the case where all parts are
-  # bundled together, should the recipient be expected to simply return a cap, so that the caller
-  # can immediately start pipelining to it?
+  # TODO(before implementing):  Change this so that multiple parts can be sent in a single Join
+  # message, so that if multiple join parts are going to cross the same connection they can be sent
+  # together, so that the receive can potentially optimize its handling of them.  In the case where
+  # all parts are bundled together, should the recipient be expected to simply return a cap, so
+  # that the caller can immediately start pipelining to it?
 }
 
 # ========================================================================================
@@ -978,7 +978,7 @@ struct Exception {
 # depending on the translations they perform.
 #
 # For interaction over the global internet between parties with no other prior arrangement, a
-# particular set of bindings for these types is defined elsewhere.  (TODO(soon): Specify where
+# particular set of bindings for these types is defined elsewhere.  (TODO(someday): Specify where
 # these common definitions live.)
 #
 # Another common network type is the two-party network, in which one of the parties typically

c++/src/kj/async.c++

@@ -163,7 +163,7 @@ public:
 private:
   TaskSet::ErrorHandler& errorHandler;
 
-  // TODO(soon):  Use a linked list instead.
+  // TODO(perf):  Use a linked list instead.
   std::map<Task*, Own<Task>> tasks;
 };