Various cleanups.

patches/v8/0002-Allow-manually-setting-ValueSerializer-format-versio.patch

@@ -3,7 +3,6 @@ From: James M Snell <jasnell@gmail.com>
 Date: Wed, 16 Mar 2022 08:59:21 -0700
 Subject: [PATCH 2/4] Allow manually setting ValueSerializer format version
 
-Refs: https://bitbucket.cfdata.org/projects/MIRRORS/repos/v8/pull-requests/2/overview
 ---
  include/v8-value-serializer.h   |  5 +++++
  src/api/api.cc                  |  4 ++++

src/workerd/api/BUILD.bazel

@@ -9,7 +9,6 @@ filegroup(
         ["**/*.c++"],
         exclude = [
             "**/*test*.c++",
-            "**/*fuzzer*.c++",
         ],
     ),
     visibility = ["//visibility:public"],

src/workerd/api/actor-state.h

@@ -3,6 +3,9 @@
 //     https://opensource.org/licenses/Apache-2.0
 
 #pragma once
+// APIs that an Actor (Durable Object) uses to access its own state.
+//
+// See actor.h for APIs used by other Workers to talk to Actors.
 
 #include <workerd/jsg/jsg.h>
 #include <workerd/io/io-context.h>

src/workerd/api/actor.h

@@ -3,6 +3,11 @@
 //     https://opensource.org/licenses/Apache-2.0
 
 #pragma once
+// "Actors" are the internal name for Durable Objects, because they implement a sort of actor
+// model. We ended up not calling the product "Actors" publicly because we found that people who
+// were familiar with actor-model programming were more confused than helped by it -- they tended
+// to expect something that looked more specifically like Erlang, whereas our actors are much more
+// abstractly related.
 
 #include <kj/async.h>
 #include <capnp/compat/byte-stream.h>
@@ -14,7 +19,7 @@
 namespace workerd::api {
 
 class ColoLocalActorNamespace: public jsg::Object {
-  // A capability to an Actor namespace.
+  // A capability to an ephemeral Actor namespace.
 
 public:
   ColoLocalActorNamespace(uint channel)

src/workerd/api/analytics-engine.h

@@ -28,11 +28,7 @@ class AnalyticsEngine: public jsg::Object {
   // `blobs` and `doubles` fields are left up to applications submitting
   // messages.
   //
-  // This project's desing closely resembles that of its dual internal tool,
-  // Ready Analytics. See this Ready Analytics FAQ for more information:
-  // https://wiki.cfops.it/display/DATA/Ready+Analytics+-+FAQ
-  // Also, see this doc on how the two differ:
-  // https://wiki.cfops.it/display/~jpl/Understanding+Ready+Analytics+and+Workers+Analytics+Engine
+  // https://blog.cloudflare.com/workers-analytics-engine/
 
 public:
   explicit AnalyticsEngine(uint logfwdrChannel, kj::String dataset,

src/workerd/api/basics.h

@@ -3,6 +3,9 @@
 //     https://opensource.org/licenses/Apache-2.0
 
 #pragma once
+// This file defines Event- and EventTarget-related APIs.
+//
+// TODO(cleanp): Rename to events.h?
 
 #include <workerd/jsg/jsg.h>
 #include <workerd/util/canceler.h>

src/workerd/api/cache.c++

@@ -364,7 +364,7 @@ jsg::Promise<void> Cache::put(
       };
 
       // A little funky: The process of "serializing" the cache entry payload means reading all the
-      // data from the payload body stream and writing it to cache. Bet, the payload body might
+      // data from the payload body stream and writing it to cache. But, the payload body might
       // originate from the app's own JavaScript, rather than being the response to some remote
       // request. If the stream is JS-backed, then we want to be careful to track "pending events".
       // Specifically, if the stream hasn't reported EOF yet, but JavaScript stops executing and

src/workerd/api/crypto.h

@@ -3,6 +3,7 @@
 //     https://opensource.org/licenses/Apache-2.0
 
 #pragma once
+// WebCrypto API
 
 #include <bit>
 #include <workerd/jsg/jsg.h>
@@ -41,7 +42,6 @@ class CryptoKeyUsageSet {
   }
 
   CryptoKeyUsageSet() : set(0) {}
-  CryptoKeyUsageSet(const CryptoKeyUsageSet& copy) : set(copy.set) {}
 
   CryptoKeyUsageSet operator&(CryptoKeyUsageSet other) const { return set & other.set; }
   CryptoKeyUsageSet operator|(CryptoKeyUsageSet other) const { return set | other.set; }

src/workerd/io/BUILD.bazel

@@ -18,7 +18,7 @@ wd_cc_library(
         ":capnp",
         "@capnp-cpp//src/kj:kj-async",
         "@com_cloudflare_lol_html//:lolhtml",
-        "//src:jaeger-model",
+        ":jaeger-model",
         "//src/workerd/api:analytics-engine_capnp",
         "//src/workerd/api:r2-api_capnp",
         "//src/workerd/jsg",
@@ -47,6 +47,22 @@ wd_cc_capnp_library(
     visibility = ["//visibility:public"],
 )
 
+cc_proto_library(
+    name = "jaeger-model",
+    deps = [":jaeger-model_proto"],
+    visibility = ["//visibility:public"],
+)
+
+proto_library(
+    name = "jaeger-model_proto",
+    srcs = ["jaeger-model.proto"],
+    deps = [
+        "@com_google_protobuf//:timestamp_proto",
+        "@com_google_protobuf//:duration_proto"
+    ],
+    strip_import_prefix = "/src",
+)
+
 [kj_test(
     src = f,
     deps = [

src/workerd/io/io-context.h

@@ -263,8 +263,6 @@ class IoContext_IncomingRequest {
 };
 
 class IoContext final: public kj::Refcounted, private kj::TaskSet::ErrorHandler {
-  // TODO(cleanup): This class will soon be renamed to IoContext.
-  //
   // IoContext holds state associated with a single I/O context. For stateless requests, each
   // incoming request runs in a unique I/O context. For actors, each actor runs in a unique I/O
   // context (but all requests received by that actor run in the same context).

src/jaeger-model.proto → src/workerd/io/jaeger-model.proto

@@ -1,3 +1,14 @@
+// This protocol is used as part of Cloudflare Workers' internal observability infrastructure,
+// which uses Jaeger. This currently isn't actually used in workerd, but is included because we
+// haven't finished the work to abstract this out from the tracing system so that we can avoid the
+// depnedency.
+//
+// workerd users who want tracing should instead get it through Trace Workers, which allows more
+// flexibility to integrate with arbitrary tracing infrastructure.
+//
+// TODO(cleanup): Finish factoring this out. We can then eliminate the dependency on protobuf
+//   altogether!
+
 // OBTAINED FROM: https://github.com/jaegertracing/jaeger-idl/blob/d64c4eb/proto/api_v2/model.proto
 // ON: 2020-05-08
 //

src/workerd/io/jaeger-test.c++

@@ -5,7 +5,7 @@
 #include <workerd/io/jaeger.h>
 #include <kj/test.h>
 #include <capnp/message.h>
-#include "jaeger-model.pb.h"
+#include <workerd/io/jaeger-model.pb.h>
 
 namespace workerd::tests {
 namespace {

src/workerd/io/jaeger.c++

@@ -3,7 +3,7 @@
 //     https://opensource.org/licenses/Apache-2.0
 
 #include "jaeger.h"
-#include <jaeger-model.pb.h>
+#include <workerd/io/jaeger-model.pb.h>
 #include <kj/debug.h>
 #include <kj/vector.h>
 #include <cstdlib>

src/workerd/io/jaeger.h

@@ -3,6 +3,13 @@
 //     https://opensource.org/licenses/Apache-2.0
 
 #pragma once
+// Similar to jaeger-model.proto, the code in this file relates to Cloudflare Workers' internal
+// tracing infrastructure, which uses Jaeger. This code is not used by `workerd` but is currenly
+// included because it is a dependency of the common trace APIs that also implement Trace Workers.
+// Eventually we would like to properly abstract trace collection and remove the Jaeger-specific
+// parts (or maybe make them available as an indepnedent library?). Long-term the right way for
+// `workerd` users to do tracing is through Trace Workers, which can integrate with arbitrary
+// tracing systems.
 
 #include <cstdint>
 #include <kj/string.h>