-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathimports.gen.go
20 lines (18 loc) · 160 KB
/
imports.gen.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Code generated by gen/imports.go. DO NOT EDIT.
package dyncapnp
// Import files collected from https://github.com/capnproto/capnproto
// Version info: 57a4ca5af5a7f55b768a9d9d6655250bffb1257f capnproto (v0.8.0)
var stdImports = map[string][]byte{
"benchmark/carsales.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\nusing Cxx = import \"/capnp/c++.capnp\";\n\n@0xff75ddc6a36723c9;\n$Cxx.namespace(\"capnp::benchmark::capnp\");\n\nstruct ParkingLot {\n cars@0: List(Car);\n}\n\nstruct TotalValue {\n amount@0: UInt64;\n}\n\nstruct Car {\n make@0: Text;\n model@1: Text;\n color@2: Color;\n seats@3: UInt8;\n doors@4: UInt8;\n wheels@5: List(Wheel);\n length@6: UInt16;\n width@7: UInt16;\n height@8: UInt16;\n weight@9: UInt32;\n engine@10: Engine;\n fuelCapacity@11: Float32;\n fuelLevel@12: Float32;\n hasPowerWindows@13: Bool;\n hasPowerSteering@14: Bool;\n hasCruiseControl@15: Bool;\n cupHolders@16: UInt8;\n hasNavSystem@17: Bool;\n}\n\nenum Color {\n black @0;\n white @1;\n red @2;\n green @3;\n blue @4;\n cyan @5;\n magenta @6;\n yellow @7;\n silver @8;\n}\n\nstruct Wheel {\n diameter@0: UInt16;\n airPressure@1: Float32;\n snowTires@2: Bool;\n}\n\nstruct Engine {\n horsepower@0: UInt16;\n cylinders@1: UInt8;\n cc@2: UInt32;\n usesGas@3: Bool;\n usesElectric@4: Bool;\n}\n"),
"benchmark/catrank.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\nusing Cxx = import \"/capnp/c++.capnp\";\n\n@0x82beb8e37ff79aba;\n$Cxx.namespace(\"capnp::benchmark::capnp\");\n\nstruct SearchResultList {\n results@0: List(SearchResult);\n}\n\nstruct SearchResult {\n url@0: Text;\n score@1: Float64;\n snippet@2: Text;\n}\n"),
"benchmark/eval.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\nusing Cxx = import \"/capnp/c++.capnp\";\n\n@0xe12dc4c3e70e9eda;\n$Cxx.namespace(\"capnp::benchmark::capnp\");\n\nenum Operation {\n add @0;\n subtract @1;\n multiply @2;\n divide @3;\n modulus @4;\n}\n\nstruct Expression {\n op@0: Operation;\n\n left :union {\n value@1: Int32;\n expression@2: Expression;\n }\n\n right :union {\n value@3: Int32;\n expression@4: Expression;\n }\n}\n\nstruct EvaluationResult {\n value@0: Int32;\n}\n"),
"capnp/c++.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\n@0xbdf87d7bb8304e81;\n$namespace(\"capnp::annotations\");\n\nannotation namespace(file): Text;\nannotation name(field, enumerant, struct, enum, interface, method, param, group, union): Text;\n"),
"capnp/persistent.capnp": []byte("# Copyright (c) 2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\n@0xb8630836983feed7;\n\n$import \"/capnp/c++.capnp\".namespace(\"capnp\");\n\ninterface Persistent@0xc8cb212fcd9f5691(SturdyRef, Owner) {\n # Interface implemented by capabilities that outlive a single connection. A client may save()\n # the capability, producing a SturdyRef. The SturdyRef can be stored to disk, then later used to\n # obtain a new reference to the capability on a future connection.\n #\n # The exact format of SturdyRef depends on the \"realm\" in which the SturdyRef appears. A \"realm\"\n # is an abstract space in which all SturdyRefs have the same format and refer to the same set of\n # resources. Every vat is in exactly one realm. All capability clients within that vat must\n # produce SturdyRefs of the format appropriate for the realm.\n #\n # Similarly, every VatNetwork also resides in a particular realm. Usually, a vat's \"realm\"\n # corresponds to the realm of its main VatNetwork. However, a Vat can in fact communicate over\n # a VatNetwork in a different realm -- in this case, all SturdyRefs need to be transformed when\n # coming or going through said VatNetwork. The RPC system has hooks for registering\n # transformation callbacks for this purpose.\n #\n # Since the format of SturdyRef is realm-dependent, it is not defined here. An application should\n # choose an appropriate realm for itself as part of its design. Note that under Sandstorm, every\n # application exists in its own realm and is therefore free to define its own SturdyRef format;\n # the Sandstorm platform handles translating between realms.\n #\n # Note that whether a capability is persistent is often orthogonal to its type. In these cases,\n # the capability's interface should NOT inherit `Persistent`; instead, just perform a cast at\n # runtime. It's not type-safe, but trying to be type-safe in these cases will likely lead to\n # tears. In cases where a particular interface only makes sense on persistent capabilities, it\n # still should not explicitly inherit Persistent because the `SturdyRef` and `Owner` types will\n # vary between realms (they may even be different at the call site than they are on the\n # implementation). Instead, mark persistent interfaces with the $persistent annotation (defined\n # below).\n #\n # Sealing\n # -------\n #\n # As an added security measure, SturdyRefs may be \"sealed\" to a particular owner, such that\n # if the SturdyRef itself leaks to a third party, that party cannot actually restore it because\n # they are not the owner. To restore a sealed capability, you must first prove to its host that\n # you are the rightful owner. The precise mechanism for this authentication is defined by the\n # realm.\n #\n # Sealing is a defense-in-depth mechanism meant to mitigate damage in the case of catastrophic\n # attacks. For example, say an attacker temporarily gains read access to a database full of\n # SturdyRefs: it would be unfortunate if it were then necessary to revoke every single reference\n # in the database to prevent the attacker from using them.\n #\n # In general, an \"owner\" is a course-grained identity. Because capability-based security is still\n # the primary mechanism of security, it is not necessary nor desirable to have a separate \"owner\"\n # identity for every single process or object; that is exactly what capabilities are supposed to\n # avoid! Instead, it makes sense for an \"owner\" to literally identify the owner of the machines\n # where the capability is stored. If untrusted third parties are able to run arbitrary code on\n # said machines, then the sandbox for that code should be designed using Distributed Confinement\n # such that the third-party code never sees the bits of the SturdyRefs and cannot directly\n # exercise the owner's power to restore refs. See:\n #\n # http://www.erights.org/elib/capability/dist-confine.html\n #\n # Resist the urge to represent an Owner as a simple public key. The whole point of sealing is to\n # defend against leaked-storage attacks. Such attacks can easily result in the owner's private\n # key being stolen as well. A better solution is for `Owner` to contain a simple globally unique\n # identifier for the owner, and for everyone to separately maintain a mapping of owner IDs to\n # public keys. If an owner's private key is compromised, then humans will need to communicate\n # and agree on a replacement public key, then update the mapping.\n #\n # As a concrete example, an `Owner` could simply contain a domain name, and restoring a SturdyRef\n # would require signing a request using the domain's private key. Authenticating this key could\n # be accomplished through certificate authorities or web-of-trust techniques.\n\n save @0 SaveParams -> SaveResults;\n # Save a capability persistently so that it can be restored by a future connection. Not all\n # capabilities can be saved -- application interfaces should define which capabilities support\n # this and which do not.\n\n struct SaveParams {\n sealFor @0 :Owner;\n # Seal the SturdyRef so that it can only be restored by the specified Owner. This is meant\n # to mitigate damage when a SturdyRef is leaked. See comments above.\n #\n # Leaving this value null may or may not be allowed; it is up to the realm to decide. If a\n # realm does allow a null owner, this should indicate that anyone is allowed to restore the\n # ref.\n }\n struct SaveResults {\n sturdyRef @0 :SturdyRef;\n }\n}\n\ninterface RealmGateway(InternalRef, ExternalRef, InternalOwner, ExternalOwner) {\n # Interface invoked when a SturdyRef is about to cross realms. The RPC system supports providing\n # a RealmGateway as a callback hook when setting up RPC over some VatNetwork.\n\n import @0 (cap :Persistent(ExternalRef, ExternalOwner),\n params :Persistent(InternalRef, InternalOwner).SaveParams)\n -> Persistent(InternalRef, InternalOwner).SaveResults;\n # Given an external capability, save it and return an internal reference. Used when someone\n # inside the realm tries to save a capability from outside the realm.\n\n export @1 (cap :Persistent(InternalRef, InternalOwner),\n params :Persistent(ExternalRef, ExternalOwner).SaveParams)\n -> Persistent(ExternalRef, ExternalOwner).SaveResults;\n # Given an internal capability, save it and return an external reference. Used when someone\n # outside the realm tries to save a capability from inside the realm.\n}\n\nannotation persistent(interface, field) :Void;\n# Apply this annotation to interfaces for objects that will always be persistent, instead of\n# extending the Persistent capability, since the correct type parameters to Persistent depend on\n# the realm, which is orthogonal to the interface type and therefore should not be defined\n# along-side it.\n#\n# You may also apply this annotation to a capability-typed field which will always contain a\n# persistent capability, but where the capability's interface itself is not already marked\n# persistent.\n#\n# Note that absence of the $persistent annotation doesn't mean a capability of that type isn't\n# persistent; it just means not *all* such capabilities are persistent.\n"),
"capnp/rpc-twoparty.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\n@0xa184c7885cdaf2a1;\n# This file defines the \"network-specific parameters\" in rpc.capnp to support a network consisting\n# of two vats. Each of these vats may in fact be in communication with other vats, but any\n# capabilities they forward must be proxied. Thus, to each end of the connection, all capabilities\n# received from the other end appear to live in a single vat.\n#\n# Two notable use cases for this model include:\n# - Regular client-server communications, where a remote client machine (perhaps living on an end\n# user's personal device) connects to a server. The server may be part of a cluster, and may\n# call on other servers in the cluster to help service the user's request. It may even obtain\n# capabilities from these other servers which it passes on to the user. To simplify network\n# common traversal problems (e.g. if the user is behind a firewall), it is probably desirable to\n# multiplex all communications between the server cluster and the client over the original\n# connection rather than form new ones. This connection should use the two-party protocol, as\n# the client has no interest in knowing about additional servers.\n# - Applications running in a sandbox. A supervisor process may execute a confined application\n# such that all of the confined app's communications with the outside world must pass through\n# the supervisor. In this case, the connection between the confined app and the supervisor might\n# as well use the two-party protocol, because the confined app is intentionally prevented from\n# talking to any other vat anyway. Any external resources will be proxied through the supervisor,\n# and so to the contained app will appear as if they were hosted by the supervisor itself.\n#\n# Since there are only two vats in this network, there is never a need for three-way introductions,\n# so level 3 is free. Moreover, because it is never necessary to form new connections, the\n# two-party protocol can be used easily anywhere where a two-way byte stream exists, without regard\n# to where that byte stream goes or how it was initiated. This makes the two-party runtime library\n# highly reusable.\n#\n# Joins (level 4) _could_ be needed in cases where one or both vats are participating in other\n# networks that use joins. For instance, if Alice and Bob are speaking through the two-party\n# protocol, and Bob is also participating on another network, Bob may send Alice two or more\n# proxied capabilities which, unbeknownst to Bob at the time, are in fact pointing at the same\n# remote object. Alice may then request to join these capabilities, at which point Bob will have\n# to forward the join to the other network. Note, however, that if Alice is _not_ participating on\n# any other network, then Alice will never need to _receive_ a Join, because Alice would always\n# know when two locally-hosted capabilities are the same and would never export a redundant alias\n# to Bob. So, Alice can respond to all incoming joins with an error, and only needs to implement\n# outgoing joins if she herself desires to use this feature. Also, outgoing joins are relatively\n# easy to implement in this scenario.\n#\n# What all this means is that a level 4 implementation of the confined network is barely more\n# complicated than a level 2 implementation. However, such an implementation allows the \"client\"\n# or \"confined\" app to access the server's/supervisor's network with equal functionality to any\n# native participant. In other words, an application which implements only the two-party protocol\n# can be paired with a proxy app in order to participate in any network.\n#\n# So, when implementing Cap'n Proto in a new language, it makes sense to implement only the\n# two-party protocol initially, and then pair applications with an appropriate proxy written in\n# C++, rather than implement other parameterizations of the RPC protocol directly.\n\nusing Cxx = import \"/capnp/c++.capnp\";\n$Cxx.namespace(\"capnp::rpc::twoparty\");\n\n# Note: SturdyRef is not specified here. It is up to the application to define semantics of\n# SturdyRefs if desired.\n\nenum Side {\n server @0;\n # The object lives on the \"server\" or \"supervisor\" end of the connection. Only the\n # server/supervisor knows how to interpret the ref; to the client, it is opaque.\n #\n # Note that containers intending to implement strong confinement should rewrite SturdyRefs\n # received from the external network before passing them on to the confined app. The confined\n # app thus does not ever receive the raw bits of the SturdyRef (which it could perhaps\n # maliciously leak), but instead receives only a thing that it can pass back to the container\n # later to restore the ref. See:\n # http://www.erights.org/elib/capability/dist-confine.html\n\n client @1;\n # The object lives on the \"client\" or \"confined app\" end of the connection. Only the client\n # knows how to interpret the ref; to the server/supervisor, it is opaque. Most clients do not\n # actually know how to persist capabilities at all, so use of this is unusual.\n}\n\nstruct VatId {\n side @0 :Side;\n}\n\nstruct ProvisionId {\n # Only used for joins, since three-way introductions never happen on a two-party network.\n\n joinId @0 :UInt32;\n # The ID from `JoinKeyPart`.\n}\n\nstruct RecipientId {}\n# Never used, because there are only two parties.\n\nstruct ThirdPartyCapId {}\n# Never used, because there is no third party.\n\nstruct JoinKeyPart {\n # Joins in the two-party case are simplified by a few observations.\n #\n # First, on a two-party network, a Join only ever makes sense if the receiving end is also\n # connected to other networks. A vat which is not connected to any other network can safely\n # reject all joins.\n #\n # Second, since a two-party connection bisects the network -- there can be no other connections\n # between the networks at either end of the connection -- if one part of a join crosses the\n # connection, then _all_ parts must cross it. Therefore, a vat which is receiving a Join request\n # off some other network which needs to be forwarded across the two-party connection can\n # collect all the parts on its end and only forward them across the two-party connection when all\n # have been received.\n #\n # For example, imagine that Alice and Bob are vats connected over a two-party connection, and\n # each is also connected to other networks. At some point, Alice receives one part of a Join\n # request off her network. The request is addressed to a capability that Alice received from\n # Bob and is proxying to her other network. Alice goes ahead and responds to the Join part as\n # if she hosted the capability locally (this is important so that if not all the Join parts end\n # up at Alice, the original sender can detect the failed Join without hanging). As other parts\n # trickle in, Alice verifies that each part is addressed to a capability from Bob and continues\n # to respond to each one. Once the complete set of join parts is received, Alice checks if they\n # were all for the exact same capability. If so, she doesn't need to send anything to Bob at\n # all. Otherwise, she collects the set of capabilities (from Bob) to which the join parts were\n # addressed and essentially initiates a _new_ Join request on those capabilities to Bob. Alice\n # does not forward the Join parts she received herself, but essentially forwards the Join as a\n # whole.\n #\n # On Bob's end, since he knows that Alice will always send all parts of a Join together, he\n # simply waits until he's received them all, then performs a join on the respective capabilities\n # as if it had been requested locally.\n\n joinId @0 :UInt32;\n # A number identifying this join, chosen by the sender. May be reused once `Finish` messages are\n # sent corresponding to all of the `Join` messages.\n\n partCount @1 :UInt16;\n # The number of capabilities to be joined.\n\n partNum @2 :UInt16;\n # Which part this request targets -- a number in the range [0, partCount).\n}\n\nstruct JoinResult {\n joinId @0 :UInt32;\n # Matches `JoinKeyPart`.\n\n succeeded @1 :Bool;\n # All JoinResults in the set will have the same value for `succeeded`. The receiver actually\n # implements the join by waiting for all the `JoinKeyParts` and then performing its own join on\n # them, then going back and answering all the join requests afterwards.\n\n cap @2 :AnyPointer;\n # One of the JoinResults will have a non-null `cap` which is the joined capability.\n #\n # TODO(cleanup): Change `AnyPointer` to `Capability` when that is supported.\n}\n"),
"capnp/rpc.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\n@0xb312981b2552a250;\n# Recall that Cap'n Proto RPC allows messages to contain references to remote objects that\n# implement interfaces. These references are called \"capabilities\", because they both designate\n# the remote object to use and confer permission to use it.\n#\n# Recall also that Cap'n Proto RPC has the feature that when a method call itself returns a\n# capability, the caller can begin calling methods on that capability _before the first call has\n# returned_. The caller essentially sends a message saying \"Hey server, as soon as you finish\n# that previous call, do this with the result!\". Cap'n Proto's RPC protocol makes this possible.\n#\n# The protocol is significantly more complicated than most RPC protocols. However, this is\n# implementation complexity that underlies an easy-to-grasp higher-level model of object oriented\n# programming. That is, just like TCP is a surprisingly complicated protocol that implements a\n# conceptually-simple byte stream abstraction, Cap'n Proto is a surprisingly complicated protocol\n# that implements a conceptually-simple object abstraction.\n#\n# Cap'n Proto RPC is based heavily on CapTP, the object-capability protocol used by the E\n# programming language:\n# http://www.erights.org/elib/distrib/captp/index.html\n#\n# Cap'n Proto RPC takes place between \"vats\". A vat hosts some set of objects and talks to other\n# vats through direct bilateral connections. Typically, there is a 1:1 correspondence between vats\n# and processes (in the unix sense of the word), although this is not strictly always true (one\n# process could run multiple vats, or a distributed virtual vat might live across many processes).\n#\n# Cap'n Proto does not distinguish between \"clients\" and \"servers\" -- this is up to the application.\n# Either end of any connection can potentially hold capabilities pointing to the other end, and\n# can call methods on those capabilities. In the doc comments below, we use the words \"sender\"\n# and \"receiver\". These refer to the sender and receiver of an instance of the struct or field\n# being documented. Sometimes we refer to a \"third-party\" that is neither the sender nor the\n# receiver. Documentation is generally written from the point of view of the sender.\n#\n# It is generally up to the vat network implementation to securely verify that connections are made\n# to the intended vat as well as to encrypt transmitted data for privacy and integrity. See the\n# `VatNetwork` example interface near the end of this file.\n#\n# When a new connection is formed, the only interesting things that can be done are to send a\n# `Bootstrap` (level 0) or `Accept` (level 3) message.\n#\n# Unless otherwise specified, messages must be delivered to the receiving application in the same\n# order in which they were initiated by the sending application. The goal is to support \"E-Order\",\n# which states that two calls made on the same reference must be delivered in the order which they\n# were made:\n# http://erights.org/elib/concurrency/partial-order.html\n#\n# Since the full protocol is complicated, we define multiple levels of support that an\n# implementation may target. For many applications, level 1 support will be sufficient.\n# Comments in this file indicate which level requires the corresponding feature to be\n# implemented.\n#\n# * **Level 0:** The implementation does not support object references. Only the bootstrap interface\n# can be called. At this level, the implementation does not support object-oriented protocols and\n# is similar in complexity to JSON-RPC or Protobuf services. This level should be considered only\n# a temporary stepping-stone toward level 1 as the lack of object references drastically changes\n# how protocols are designed. Applications _should not_ attempt to design their protocols around\n# the limitations of level 0 implementations.\n#\n# * **Level 1:** The implementation supports simple bilateral interaction with object references\n# and promise pipelining, but interactions between three or more parties are supported only via\n# proxying of objects. E.g. if Alice (in Vat A) wants to send Bob (in Vat B) a capability\n# pointing to Carol (in Vat C), Alice must create a proxy of Carol within Vat A and send Bob a\n# reference to that; Bob cannot form a direct connection to Carol. Level 1 implementations do\n# not support checking if two capabilities received from different vats actually point to the\n# same object (\"join\"), although they should be able to do this check on capabilities received\n# from the same vat.\n#\n# * **Level 2:** The implementation supports saving persistent capabilities -- i.e. capabilities\n# that remain valid even after disconnect, and can be restored on a future connection. When a\n# capability is saved, the requester receives a `SturdyRef`, which is a token that can be used\n# to restore the capability later.\n#\n# * **Level 3:** The implementation supports three-way interactions. That is, if Alice (in Vat A)\n# sends Bob (in Vat B) a capability pointing to Carol (in Vat C), then Vat B will automatically\n# form a direct connection to Vat C rather than have requests be proxied through Vat A.\n#\n# * **Level 4:** The entire protocol is implemented, including joins (checking if two capabilities\n# are equivalent).\n#\n# Note that an implementation must also support specific networks (transports), as described in\n# the \"Network-specific Parameters\" section below. An implementation might have different levels\n# depending on the network used.\n#\n# New implementations of Cap'n Proto should start out targeting the simplistic two-party network\n# type as defined in `rpc-twoparty.capnp`. With this network type, level 3 is irrelevant and\n# levels 2 and 4 are much easier than usual to implement. When such an implementation is paired\n# with a container proxy, the contained app effectively gets to make full use of the proxy's\n# network at level 4. And since Cap'n Proto IPC is extremely fast, it may never make sense to\n# bother implementing any other vat network protocol -- just use the correct container type and get\n# it for free.\n\nusing Cxx = import \"/capnp/c++.capnp\";\n$Cxx.namespace(\"capnp::rpc\");\n\n# ========================================================================================\n# The Four Tables\n#\n# Cap'n Proto RPC connections are stateful (although an application built on Cap'n Proto could\n# export a stateless interface). As in CapTP, for each open connection, a vat maintains four state\n# tables: questions, answers, imports, and exports. See the diagram at:\n# http://www.erights.org/elib/distrib/captp/4tables.html\n#\n# The question table corresponds to the other end's answer table, and the imports table corresponds\n# to the other end's exports table.\n#\n# The entries in each table are identified by ID numbers (defined below as 32-bit integers). These\n# numbers are always specific to the connection; a newly-established connection starts with no\n# valid IDs. Since low-numbered IDs will pack better, it is suggested that IDs be assigned like\n# Unix file descriptors -- prefer the lowest-number ID that is currently available.\n#\n# IDs in the questions/answers tables are chosen by the questioner and generally represent method\n# calls that are in progress.\n#\n# IDs in the imports/exports tables are chosen by the exporter and generally represent objects on\n# which methods may be called. Exports may be \"settled\", meaning the exported object is an actual\n# object living in the exporter's vat, or they may be \"promises\", meaning the exported object is\n# the as-yet-unknown result of an ongoing operation and will eventually be resolved to some other\n# object once that operation completes. Calls made to a promise will be forwarded to the eventual\n# target once it is known. The eventual replacement object does *not* get the same ID as the\n# promise, as it may turn out to be an object that is already exported (so already has an ID) or\n# may even live in a completely different vat (and so won't get an ID on the same export table\n# at all).\n#\n# IDs can be reused over time. To make this safe, we carefully define the lifetime of IDs. Since\n# messages using the ID could be traveling in both directions simultaneously, we must define the\n# end of life of each ID _in each direction_. The ID is only safe to reuse once it has been\n# released by both sides.\n#\n# When a Cap'n Proto connection is lost, everything on the four tables is lost. All questions are\n# canceled and throw exceptions. All imports become broken (all future calls to them throw\n# exceptions). All exports and answers are implicitly released. The only things not lost are\n# persistent capabilities (`SturdyRef`s). The application must plan for this and should respond by\n# establishing a new connection and restoring from these persistent capabilities.\n\nusing QuestionId = UInt32;\n# **(level 0)**\n#\n# Identifies a question in the sender's question table (which corresponds to the receiver's answer\n# table). The questioner (caller) chooses an ID when making a call. The ID remains valid in\n# caller -> callee messages until a Finish message is sent, and remains valid in callee -> caller\n# messages until a Return message is sent.\n\nusing AnswerId = QuestionId;\n# **(level 0)**\n#\n# Identifies an answer in the sender's answer table (which corresponds to the receiver's question\n# table).\n#\n# AnswerId is physically equivalent to QuestionId, since the question and answer tables correspond,\n# but we define a separate type for documentation purposes: we always use the type representing\n# the sender's point of view.\n\nusing ExportId = UInt32;\n# **(level 1)**\n#\n# Identifies an exported capability or promise in the sender's export table (which corresponds\n# to the receiver's import table). The exporter chooses an ID before sending a capability over the\n# wire. If the capability is already in the table, the exporter should reuse the same ID. If the\n# ID is a promise (as opposed to a settled capability), this must be indicated at the time the ID\n# is introduced (e.g. by using `senderPromise` instead of `senderHosted` in `CapDescriptor`); in\n# this case, the importer shall expect a later `Resolve` message that replaces the promise.\n#\n# ExportId/ImportIds are subject to reference counting. Whenever an `ExportId` is sent over the\n# wire (from the exporter to the importer), the export's reference count is incremented (unless\n# otherwise specified). The reference count is later decremented by a `Release` message. Since\n# the `Release` message can specify an arbitrary number by which to reduce the reference count, the\n# importer should usually batch reference decrements and only send a `Release` when it believes the\n# reference count has hit zero. Of course, it is possible that a new reference to the export is\n# in-flight at the time that the `Release` message is sent, so it is necessary for the exporter to\n# keep track of the reference count on its end as well to avoid race conditions.\n#\n# When a connection is lost, all exports are implicitly released. It is not possible to restore\n# a connection state after disconnect (although a transport layer could implement a concept of\n# persistent connections if it is transparent to the RPC layer).\n\nusing ImportId = ExportId;\n# **(level 1)**\n#\n# Identifies an imported capability or promise in the sender's import table (which corresponds to\n# the receiver's export table).\n#\n# ImportId is physically equivalent to ExportId, since the export and import tables correspond,\n# but we define a separate type for documentation purposes: we always use the type representing\n# the sender's point of view.\n#\n# An `ImportId` remains valid in importer -> exporter messages until the importer has sent\n# `Release` messages that (it believes) have reduced the reference count to zero.\n\n# ========================================================================================\n# Messages\n\nstruct Message {\n # An RPC connection is a bi-directional stream of Messages.\n\n union {\n unimplemented @0 :Message;\n # The sender previously received this message from the peer but didn't understand it or doesn't\n # yet implement the functionality that was requested. So, the sender is echoing the message\n # back. In some cases, the receiver may be able to recover from this by pretending the sender\n # had taken some appropriate \"null\" action.\n #\n # For example, say `resolve` is received by a level 0 implementation (because a previous call\n # or return happened to contain a promise). The level 0 implementation will echo it back as\n # `unimplemented`. The original sender can then simply release the cap to which the promise\n # had resolved, thus avoiding a leak.\n #\n # For any message type that introduces a question, if the message comes back unimplemented,\n # the original sender may simply treat it as if the question failed with an exception.\n #\n # In cases where there is no sensible way to react to an `unimplemented` message (without\n # resource leaks or other serious problems), the connection may need to be aborted. This is\n # a gray area; different implementations may take different approaches.\n\n abort @1 :Exception;\n # Sent when a connection is being aborted due to an unrecoverable error. This could be e.g.\n # because the sender received an invalid or nonsensical message or because the sender had an\n # internal error. The sender will shut down the outgoing half of the connection after `abort`\n # and will completely close the connection shortly thereafter (it's up to the sender how much\n # of a time buffer they want to offer for the client to receive the `abort` before the\n # connection is reset).\n\n # Level 0 features -----------------------------------------------\n\n bootstrap @8 :Bootstrap; # Request the peer's bootstrap interface.\n call @2 :Call; # Begin a method call.\n return @3 :Return; # Complete a method call.\n finish @4 :Finish; # Release a returned answer / cancel a call.\n\n # Level 1 features -----------------------------------------------\n\n resolve @5 :Resolve; # Resolve a previously-sent promise.\n release @6 :Release; # Release a capability so that the remote object can be deallocated.\n disembargo @13 :Disembargo; # Lift an embargo used to enforce E-order over promise resolution.\n\n # Level 2 features -----------------------------------------------\n\n obsoleteSave @7 :AnyPointer;\n # Obsolete request to save a capability, resulting in a SturdyRef. This has been replaced\n # by the `Persistent` interface defined in `persistent.capnp`. This operation was never\n # implemented.\n\n obsoleteDelete @9 :AnyPointer;\n # Obsolete way to delete a SturdyRef. This operation was never implemented.\n\n # Level 3 features -----------------------------------------------\n\n provide @10 :Provide; # Provide a capability to a third party.\n accept @11 :Accept; # Accept a capability provided by a third party.\n\n # Level 4 features -----------------------------------------------\n\n join @12 :Join; # Directly connect to the common root of two or more proxied caps.\n }\n}\n\n# Level 0 message types ----------------------------------------------\n\nstruct Bootstrap {\n # **(level 0)**\n #\n # Get the \"bootstrap\" interface exported by the remote vat.\n #\n # For level 0, 1, and 2 implementations, the \"bootstrap\" interface is simply the main interface\n # exported by a vat. If the vat acts as a server fielding connections from clients, then the\n # bootstrap interface defines the basic functionality available to a client when it connects.\n # The exact interface definition obviously depends on the application.\n #\n # We call this a \"bootstrap\" because in an ideal Cap'n Proto world, bootstrap interfaces would\n # never be used. In such a world, any time you connect to a new vat, you do so because you\n # received an introduction from some other vat (see `ThirdPartyCapId`). Thus, the first message\n # you send is `Accept`, and further communications derive from there. `Bootstrap` is not used.\n #\n # In such an ideal world, DNS itself would support Cap'n Proto -- performing a DNS lookup would\n # actually return a new Cap'n Proto capability, thus introducing you to the target system via\n # level 3 RPC. Applications would receive the capability to talk to DNS in the first place as\n # an initial endowment or part of a Powerbox interaction. Therefore, an app can form arbitrary\n # connections without ever using `Bootstrap`.\n #\n # Of course, in the real world, DNS is not Cap'n-Proto-based, and we don't want Cap'n Proto to\n # require a whole new internet infrastructure to be useful. Therefore, we offer bootstrap\n # interfaces as a way to get up and running without a level 3 introduction. Thus, bootstrap\n # interfaces are used to \"bootstrap\" from other, non-Cap'n-Proto-based means of service discovery,\n # such as legacy DNS.\n #\n # Note that a vat need not provide a bootstrap interface, and in fact many vats (especially those\n # acting as clients) do not. In this case, the vat should either reply to `Bootstrap` with a\n # `Return` indicating an exception, or should return a dummy capability with no methods.\n\n questionId @0 :QuestionId;\n # A new question ID identifying this request, which will eventually receive a Return message\n # containing the restored capability.\n\n deprecatedObjectId @1 :AnyPointer;\n # ** DEPRECATED **\n #\n # A Vat may export multiple bootstrap interfaces. In this case, `deprecatedObjectId` specifies\n # which one to return. If this pointer is null, then the default bootstrap interface is returned.\n #\n # As of verison 0.5, use of this field is deprecated. If a service wants to export multiple\n # bootstrap interfaces, it should instead define a single bootstrap interface that has methods\n # that return each of the other interfaces.\n #\n # **History**\n #\n # In the first version of Cap'n Proto RPC (0.4.x) the `Bootstrap` message was called `Restore`.\n # At the time, it was thought that this would eventually serve as the way to restore SturdyRefs\n # (level 2). Meanwhile, an application could offer its \"main\" interface on a well-known\n # (non-secret) SturdyRef.\n #\n # Since level 2 RPC was not implemented at the time, the `Restore` message was in practice only\n # used to obtain the main interface. Since most applications had only one main interface that\n # they wanted to restore, they tended to designate this with a null `objectId`.\n #\n # Unfortunately, the earliest version of the EZ RPC interfaces set a precedent of exporting\n # multiple main interfaces by allowing them to be exported under string names. In this case,\n # `objectId` was a Text value specifying the name.\n #\n # All of this proved problematic for several reasons:\n #\n # - The arrangement assumed that a client wishing to restore a SturdyRef would know exactly what\n # machine to connect to and would be able to immediately restore a SturdyRef on connection.\n # However, in practice, the ability to restore SturdyRefs is itself a capability that may\n # require going through an authentication process to obtain. Thus, it makes more sense to\n # define a \"restorer service\" as a full Cap'n Proto interface. If this restorer interface is\n # offered as the vat's bootstrap interface, then this is equivalent to the old arrangement.\n #\n # - Overloading \"Restore\" for the purpose of obtaining well-known capabilities encouraged the\n # practice of exporting singleton services with string names. If singleton services are desired,\n # it is better to have one main interface that has methods that can be used to obtain each\n # service, in order to get all the usual benefits of schemas and type checking.\n #\n # - Overloading \"Restore\" also had a security problem: Often, \"main\" or \"well-known\"\n # capabilities exported by a vat are in fact not public: they are intended to be accessed only\n # by clients who are capable of forming a connection to the vat. This can lead to trouble if\n # the client itself has other clients and wishes to foward some `Restore` requests from those\n # external clients -- it has to be very careful not to allow through `Restore` requests\n # addressing the default capability.\n #\n # For example, consider the case of a sandboxed Sandstorm application and its supervisor. The\n # application exports a default capability to its supervisor that provides access to\n # functionality that only the supervisor is supposed to access. Meanwhile, though, applications\n # may publish other capabilities that may be persistent, in which case the application needs\n # to field `Restore` requests that could come from anywhere. These requests of course have to\n # pass through the supervisor, as all communications with the outside world must. But, the\n # supervisor has to be careful not to honor an external request addressing the application's\n # default capability, since this capability is privileged. Unfortunately, the default\n # capability cannot be given an unguessable name, because then the supervisor itself would not\n # be able to address it!\n #\n # As of Cap'n Proto 0.5, `Restore` has been renamed to `Bootstrap` and is no longer planned for\n # use in restoring SturdyRefs.\n #\n # Note that 0.4 also defined a message type called `Delete` that, like `Restore`, addressed a\n # SturdyRef, but indicated that the client would not restore the ref again in the future. This\n # operation was never implemented, so it was removed entirely. If a \"delete\" operation is desired,\n # it should exist as a method on the same interface that handles restoring SturdyRefs. However,\n # the utility of such an operation is questionable. You wouldn't be able to rely on it for\n # garbage collection since a client could always disappear permanently without remembering to\n # delete all its SturdyRefs, thus leaving them dangling forever. Therefore, it is advisable to\n # design systems such that SturdyRefs never represent \"owned\" pointers.\n #\n # For example, say a SturdyRef points to an image file hosted on some server. That image file\n # should also live inside a collection (a gallery, perhaps) hosted on the same server, owned by\n # a user who can delete the image at any time. If the user deletes the image, the SturdyRef\n # stops working. On the other hand, if the SturdyRef is discarded, this has no effect on the\n # existence of the image in its collection.\n}\n\nstruct Call {\n # **(level 0)**\n #\n # Message type initiating a method call on a capability.\n\n questionId @0 :QuestionId;\n # A number, chosen by the caller, that identifies this call in future messages. This number\n # must be different from all other calls originating from the same end of the connection (but\n # may overlap with question IDs originating from the opposite end). A fine strategy is to use\n # sequential question IDs, but the recipient should not assume this.\n #\n # A question ID can be reused once both:\n # - A matching Return has been received from the callee.\n # - A matching Finish has been sent from the caller.\n\n target @1 :MessageTarget;\n # The object that should receive this call.\n\n interfaceId @2 :UInt64;\n # The type ID of the interface being called. Each capability may implement multiple interfaces.\n\n methodId @3 :UInt16;\n # The ordinal number of the method to call within the requested interface.\n\n allowThirdPartyTailCall @8 :Bool = false;\n # Indicates whether or not the receiver is allowed to send a `Return` containing\n # `acceptFromThirdParty`. Level 3 implementations should set this true. Otherwise, the callee\n # will have to proxy the return in the case of a tail call to a third-party vat.\n\n params @4 :Payload;\n # The call parameters. `params.content` is a struct whose fields correspond to the parameters of\n # the method.\n\n sendResultsTo :union {\n # Where should the return message be sent?\n\n caller @5 :Void;\n # Send the return message back to the caller (the usual).\n\n yourself @6 :Void;\n # **(level 1)**\n #\n # Don't actually return the results to the sender. Instead, hold on to them and await\n # instructions from the sender regarding what to do with them. In particular, the sender\n # may subsequently send a `Return` for some other call (which the receiver had previously made\n # to the sender) with `takeFromOtherQuestion` set. The results from this call are then used\n # as the results of the other call.\n #\n # When `yourself` is used, the receiver must still send a `Return` for the call, but sets the\n # field `resultsSentElsewhere` in that `Return` rather than including the results.\n #\n # This feature can be used to implement tail calls in which a call from Vat A to Vat B ends up\n # returning the result of a call from Vat B back to Vat A.\n #\n # In particular, the most common use case for this feature is when Vat A makes a call to a\n # promise in Vat B, and then that promise ends up resolving to a capability back in Vat A.\n # Vat B must forward all the queued calls on that promise back to Vat A, but can set `yourself`\n # in the calls so that the results need not pass back through Vat B.\n #\n # For example:\n # - Alice, in Vat A, calls foo() on Bob in Vat B.\n # - Alice makes a pipelined call bar() on the promise returned by foo().\n # - Later on, Bob resolves the promise from foo() to point at Carol, who lives in Vat A (next\n # to Alice).\n # - Vat B dutifully forwards the bar() call to Carol. Let us call this forwarded call bar'().\n # Notice that bar() and bar'() are travelling in opposite directions on the same network\n # link.\n # - The `Call` for bar'() has `sendResultsTo` set to `yourself`.\n # - Vat B sends a `Return` for bar() with `takeFromOtherQuestion` set in place of the results,\n # with the value set to the question ID of bar'(). Vat B does not wait for bar'() to return,\n # as doing so would introduce unnecessary round trip latency.\n # - Vat A receives bar'() and delivers it to Carol.\n # - When bar'() returns, Vat A sends a `Return` for bar'() to Vat B, with `resultsSentElsewhere`\n # set in place of results.\n # - Vat A sends a `Finish` for the bar() call to Vat B.\n # - Vat B receives the `Finish` for bar() and sends a `Finish` for bar'().\n\n thirdParty @7 :RecipientId;\n # **(level 3)**\n #\n # The call's result should be returned to a different vat. The receiver (the callee) expects\n # to receive an `Accept` message from the indicated vat, and should return the call's result\n # to it, rather than to the sender of the `Call`.\n #\n # This operates much like `yourself`, above, except that Carol is in a separate Vat C. `Call`\n # messages are sent from Vat A -> Vat B and Vat B -> Vat C. A `Return` message is sent from\n # Vat B -> Vat A that contains `acceptFromThirdParty` in place of results. When Vat A sends\n # an `Accept` to Vat C, it receives back a `Return` containing the call's actual result. Vat C\n # also sends a `Return` to Vat B with `resultsSentElsewhere`.\n }\n}\n\nstruct Return {\n # **(level 0)**\n #\n # Message type sent from callee to caller indicating that the call has completed.\n\n answerId @0 :AnswerId;\n # Equal to the QuestionId of the corresponding `Call` message.\n\n releaseParamCaps @1 :Bool = true;\n # If true, all capabilities that were in the params should be considered released. The sender\n # must not send separate `Release` messages for them. Level 0 implementations in particular\n # should always set this true. This defaults true because if level 0 implementations forget to\n # set it they'll never notice (just silently leak caps), but if level >=1 implementations forget\n # to set it to false they'll quickly get errors.\n #\n # The receiver should act as if the sender had sent a release message with count=1 for each\n # CapDescriptor in the original Call message.\n\n union {\n results @2 :Payload;\n # The result.\n #\n # For regular method calls, `results.content` points to the result struct.\n #\n # For a `Return` in response to an `Accept` or `Bootstrap`, `results` contains a single\n # capability (rather than a struct), and `results.content` is just a capability pointer with\n # index 0. A `Finish` is still required in this case.\n\n exception @3 :Exception;\n # Indicates that the call failed and explains why.\n\n canceled @4 :Void;\n # Indicates that the call was canceled due to the caller sending a Finish message\n # before the call had completed.\n\n resultsSentElsewhere @5 :Void;\n # This is set when returning from a `Call` that had `sendResultsTo` set to something other\n # than `caller`.\n #\n # It doesn't matter too much when this is sent, as the receiver doesn't need to do anything\n # with it, but the C++ implementation appears to wait for the call to finish before sending\n # this.\n\n takeFromOtherQuestion @6 :QuestionId;\n # The sender has also sent (before this message) a `Call` with the given question ID and with\n # `sendResultsTo.yourself` set, and the results of that other call should be used as the\n # results here. `takeFromOtherQuestion` can only used once per question.\n\n acceptFromThirdParty @7 :ThirdPartyCapId;\n # **(level 3)**\n #\n # The caller should contact a third-party vat to pick up the results. An `Accept` message\n # sent to the vat will return the result. This pairs with `Call.sendResultsTo.thirdParty`.\n # It should only be used if the corresponding `Call` had `allowThirdPartyTailCall` set.\n }\n}\n\nstruct Finish {\n # **(level 0)**\n #\n # Message type sent from the caller to the callee to indicate:\n # 1) The questionId will no longer be used in any messages sent by the callee (no further\n # pipelined requests).\n # 2) If the call has not returned yet, the caller no longer cares about the result. If nothing\n # else cares about the result either (e.g. there are no other outstanding calls pipelined on\n # the result of this one) then the callee may wish to immediately cancel the operation and\n # send back a Return message with \"canceled\" set. However, implementations are not required\n # to support premature cancellation -- instead, the implementation may wait until the call\n # actually completes and send a normal `Return` message.\n #\n # TODO(someday): Should we separate (1) and implicitly releasing result capabilities? It would be\n # possible and useful to notify the server that it doesn't need to keep around the response to\n # service pipeline requests even though the caller still wants to receive it / hasn't yet\n # finished processing it. It could also be useful to notify the server that it need not marshal\n # the results because the caller doesn't want them anyway, even if the caller is still sending\n # pipelined calls, although this seems less useful (just saving some bytes on the wire).\n\n questionId @0 :QuestionId;\n # ID of the call whose result is to be released.\n\n releaseResultCaps @1 :Bool = true;\n # If true, all capabilities that were in the results should be considered released. The sender\n # must not send separate `Release` messages for them. Level 0 implementations in particular\n # should always set this true. This defaults true because if level 0 implementations forget to\n # set it they'll never notice (just silently leak caps), but if level >=1 implementations forget\n # set it false they'll quickly get errors.\n}\n\n# Level 1 message types ----------------------------------------------\n\nstruct Resolve {\n # **(level 1)**\n #\n # Message type sent to indicate that a previously-sent promise has now been resolved to some other\n # object (possibly another promise) -- or broken, or canceled.\n #\n # Keep in mind that it's possible for a `Resolve` to be sent to a level 0 implementation that\n # doesn't implement it. For example, a method call or return might contain a capability in the\n # payload. Normally this is fine even if the receiver is level 0, because they will implicitly\n # release all such capabilities on return / finish. But if the cap happens to be a promise, then\n # a follow-up `Resolve` may be sent regardless of this release. The level 0 receiver will reply\n # with an `unimplemented` message, and the sender (of the `Resolve`) can respond to this as if the\n # receiver had immediately released any capability to which the promise resolved.\n #\n # When implementing promise resolution, it's important to understand how embargos work and the\n # tricky case of the Tribble 4-way race condition. See the comments for the Disembargo message,\n # below.\n\n promiseId @0 :ExportId;\n # The ID of the promise to be resolved.\n #\n # Unlike all other instances of `ExportId` sent from the exporter, the `Resolve` message does\n # _not_ increase the reference count of `promiseId`. In fact, it is expected that the receiver\n # will release the export soon after receiving `Resolve`, and the sender will not send this\n # `ExportId` again until it has been released and recycled.\n #\n # When an export ID sent over the wire (e.g. in a `CapDescriptor`) is indicated to be a promise,\n # this indicates that the sender will follow up at some point with a `Resolve` message. If the\n # same `promiseId` is sent again before `Resolve`, still only one `Resolve` is sent. If the\n # same ID is sent again later _after_ a `Resolve`, it can only be because the export's\n # reference count hit zero in the meantime and the ID was re-assigned to a new export, therefore\n # this later promise does _not_ correspond to the earlier `Resolve`.\n #\n # If a promise ID's reference count reaches zero before a `Resolve` is sent, the `Resolve`\n # message may or may not still be sent (the `Resolve` may have already been in-flight when\n # `Release` was sent, but if the `Release` is received before `Resolve` then there is no longer\n # any reason to send a `Resolve`). Thus a `Resolve` may be received for a promise of which\n # the receiver has no knowledge, because it already released it earlier. In this case, the\n # receiver should simply release the capability to which the promise resolved.\n\n union {\n cap @1 :CapDescriptor;\n # The object to which the promise resolved.\n #\n # The sender promises that from this point forth, until `promiseId` is released, it shall\n # simply forward all messages to the capability designated by `cap`. This is true even if\n # `cap` itself happens to designate another promise, and that other promise later resolves --\n # messages sent to `promiseId` shall still go to that other promise, not to its resolution.\n # This is important in the case that the receiver of the `Resolve` ends up sending a\n # `Disembargo` message towards `promiseId` in order to control message ordering -- that\n # `Disembargo` really needs to reflect back to exactly the object designated by `cap` even\n # if that object is itself a promise.\n\n exception @2 :Exception;\n # Indicates that the promise was broken.\n }\n}\n\nstruct Release {\n # **(level 1)**\n #\n # Message type sent to indicate that the sender is done with the given capability and the receiver\n # can free resources allocated to it.\n\n id @0 :ImportId;\n # What to release.\n\n referenceCount @1 :UInt32;\n # The amount by which to decrement the reference count. The export is only actually released\n # when the reference count reaches zero.\n}\n\nstruct Disembargo {\n # **(level 1)**\n #\n # Message sent to indicate that an embargo on a recently-resolved promise may now be lifted.\n #\n # Embargos are used to enforce E-order in the presence of promise resolution. That is, if an\n # application makes two calls foo() and bar() on the same capability reference, in that order,\n # the calls should be delivered in the order in which they were made. But if foo() is called\n # on a promise, and that promise happens to resolve before bar() is called, then the two calls\n # may travel different paths over the network, and thus could arrive in the wrong order. In\n # this case, the call to `bar()` must be embargoed, and a `Disembargo` message must be sent along\n # the same path as `foo()` to ensure that the `Disembargo` arrives after `foo()`. Once the\n # `Disembargo` arrives, `bar()` can then be delivered.\n #\n # There are two particular cases where embargos are important. Consider object Alice, in Vat A,\n # who holds a promise P, pointing towards Vat B, that eventually resolves to Carol. The two\n # cases are:\n # - Carol lives in Vat A, i.e. next to Alice. In this case, Vat A needs to send a `Disembargo`\n # message that echos through Vat B and back, to ensure that all pipelined calls on the promise\n # have been delivered.\n # - Carol lives in a different Vat C. When the promise resolves, a three-party handoff occurs\n # (see `Provide` and `Accept`, which constitute level 3 of the protocol). In this case, we\n # piggyback on the state that has already been set up to handle the handoff: the `Accept`\n # message (from Vat A to Vat C) is embargoed, as are all pipelined messages sent to it, while\n # a `Disembargo` message is sent from Vat A through Vat B to Vat C. See `Accept.embargo` for\n # an example.\n #\n # Note that in the case where Carol actually lives in Vat B (i.e., the same vat that the promise\n # already pointed at), no embargo is needed, because the pipelined calls are delivered over the\n # same path as the later direct calls.\n #\n # Keep in mind that promise resolution happens both in the form of Resolve messages as well as\n # Return messages (which resolve PromisedAnswers). Embargos apply in both cases.\n #\n # An alternative strategy for enforcing E-order over promise resolution could be for Vat A to\n # implement the embargo internally. When Vat A is notified of promise resolution, it could\n # send a dummy no-op call to promise P and wait for it to complete. Until that call completes,\n # all calls to the capability are queued locally. This strategy works, but is pessimistic:\n # in the three-party case, it requires an A -> B -> C -> B -> A round trip before calls can start\n # being delivered directly to from Vat A to Vat C. The `Disembargo` message allows latency to be\n # reduced. (In the two-party loopback case, the `Disembargo` message is just a more explicit way\n # of accomplishing the same thing as a no-op call, but isn't any faster.)\n #\n # *The Tribble 4-way Race Condition*\n #\n # Any implementation of promise resolution and embargos must be aware of what we call the\n # \"Tribble 4-way race condition\", after Dean Tribble, who explained the problem in a lively\n # Friam meeting.\n #\n # Embargos are designed to work in the case where a two-hop path is being shortened to one hop.\n # But sometimes there are more hops. Imagine that Alice has a reference to a remote promise P1\n # that eventually resolves to _another_ remote promise P2 (in a third vat), which _at the same\n # time_ happens to resolve to Bob (in a fourth vat). In this case, we're shortening from a 3-hop\n # path (with four parties) to a 1-hop path (Alice -> Bob).\n #\n # Extending the embargo/disembargo protocol to be able to shorted multiple hops at once seems\n # difficult. Instead, we make a rule that prevents this case from coming up:\n #\n # One a promise P has been resolved to a remote object reference R, then all further messages\n # received addressed to P will be forwarded strictly to R. Even if it turns out later that R is\n # itself a promise, and has resolved to some other object Q, messages sent to P will still be\n # forwarded to R, not directly to Q (R will of course further forward the messages to Q).\n #\n # This rule does not cause a significant performance burden because once P has resolved to R, it\n # is expected that people sending messages to P will shortly start sending them to R instead and\n # drop P. P is at end-of-life anyway, so it doesn't matter if it ignores chances to further\n # optimize its path.\n\n target @0 :MessageTarget;\n # What is to be disembargoed.\n\n using EmbargoId = UInt32;\n # Used in `senderLoopback` and `receiverLoopback`, below.\n\n context :union {\n senderLoopback @1 :EmbargoId;\n # The sender is requesting a disembargo on a promise that is known to resolve back to a\n # capability hosted by the sender. As soon as the receiver has echoed back all pipelined calls\n # on this promise, it will deliver the Disembargo back to the sender with `receiverLoopback`\n # set to the same value as `senderLoopback`. This value is chosen by the sender, and since\n # it is also consumed be the sender, the sender can use whatever strategy it wants to make sure\n # the value is unambiguous.\n #\n # The receiver must verify that the target capability actually resolves back to the sender's\n # vat. Otherwise, the sender has committed a protocol error and should be disconnected.\n\n receiverLoopback @2 :EmbargoId;\n # The receiver previously sent a `senderLoopback` Disembargo towards a promise resolving to\n # this capability, and that Disembargo is now being echoed back.\n\n accept @3 :Void;\n # **(level 3)**\n #\n # The sender is requesting a disembargo on a promise that is known to resolve to a third-party\n # capability that the sender is currently in the process of accepting (using `Accept`).\n # The receiver of this `Disembargo` has an outstanding `Provide` on said capability. The\n # receiver should now send a `Disembargo` with `provide` set to the question ID of that\n # `Provide` message.\n #\n # See `Accept.embargo` for an example.\n\n provide @4 :QuestionId;\n # **(level 3)**\n #\n # The sender is requesting a disembargo on a capability currently being provided to a third\n # party. The question ID identifies the `Provide` message previously sent by the sender to\n # this capability. On receipt, the receiver (the capability host) shall release the embargo\n # on the `Accept` message that it has received from the third party. See `Accept.embargo` for\n # an example.\n }\n}\n\n# Level 2 message types ----------------------------------------------\n\n# See persistent.capnp.\n\n# Level 3 message types ----------------------------------------------\n\nstruct Provide {\n # **(level 3)**\n #\n # Message type sent to indicate that the sender wishes to make a particular capability implemented\n # by the receiver available to a third party for direct access (without the need for the third\n # party to proxy through the sender).\n #\n # (In CapTP, `Provide` and `Accept` are methods of the global `NonceLocator` object exported by\n # every vat. In Cap'n Proto, we bake this into the core protocol.)\n\n questionId @0 :QuestionId;\n # Question ID to be held open until the recipient has received the capability. A result will be\n # returned once the third party has successfully received the capability. The sender must at some\n # point send a `Finish` message as with any other call, and that message can be used to cancel the\n # whole operation.\n\n target @1 :MessageTarget;\n # What is to be provided to the third party.\n\n recipient @2 :RecipientId;\n # Identity of the third party that is expected to pick up the capability.\n}\n\nstruct Accept {\n # **(level 3)**\n #\n # Message type sent to pick up a capability hosted by the receiving vat and provided by a third\n # party. The third party previously designated the capability using `Provide`.\n #\n # This message is also used to pick up a redirected return -- see `Return.acceptFromThirdParty`.\n\n questionId @0 :QuestionId;\n # A new question ID identifying this accept message, which will eventually receive a Return\n # message containing the provided capability (or the call result in the case of a redirected\n # return).\n\n provision @1 :ProvisionId;\n # Identifies the provided object to be picked up.\n\n embargo @2 :Bool;\n # If true, this accept shall be temporarily embargoed. The resulting `Return` will not be sent,\n # and any pipelined calls will not be delivered, until the embargo is released. The receiver\n # (the capability host) will expect the provider (the vat that sent the `Provide` message) to\n # eventually send a `Disembargo` message with the field `context.provide` set to the question ID\n # of the original `Provide` message. At that point, the embargo is released and the queued\n # messages are delivered.\n #\n # For example:\n # - Alice, in Vat A, holds a promise P, which currently points toward Vat B.\n # - Alice calls foo() on P. The `Call` message is sent to Vat B.\n # - The promise P in Vat B ends up resolving to Carol, in Vat C.\n # - Vat B sends a `Provide` message to Vat C, identifying Vat A as the recipient.\n # - Vat B sends a `Resolve` message to Vat A, indicating that the promise has resolved to a\n # `ThirdPartyCapId` identifying Carol in Vat C.\n # - Vat A sends an `Accept` message to Vat C to pick up the capability. Since Vat A knows that\n # it has an outstanding call to the promise, it sets `embargo` to `true` in the `Accept`\n # message.\n # - Vat A sends a `Disembargo` message to Vat B on promise P, with `context.accept` set.\n # - Alice makes a call bar() to promise P, which is now pointing towards Vat C. Alice doesn't\n # know anything about the mechanics of promise resolution happening under the hood, but she\n # expects that bar() will be delivered after foo() because that is the order in which she\n # initiated the calls.\n # - Vat A sends the bar() call to Vat C, as a pipelined call on the result of the `Accept` (which\n # hasn't returned yet, due to the embargo). Since calls to the newly-accepted capability\n # are embargoed, Vat C does not deliver the call yet.\n # - At some point, Vat B forwards the foo() call from the beginning of this example on to Vat C.\n # - Vat B forwards the `Disembargo` from Vat A on to vat C. It sets `context.provide` to the\n # question ID of the `Provide` message it had sent previously.\n # - Vat C receives foo() before `Disembargo`, thus allowing it to correctly deliver foo()\n # before delivering bar().\n # - Vat C receives `Disembargo` from Vat B. It can now send a `Return` for the `Accept` from\n # Vat A, as well as deliver bar().\n}\n\n# Level 4 message types ----------------------------------------------\n\nstruct Join {\n # **(level 4)**\n #\n # Message type sent to implement E.join(), which, given a number of capabilities that are\n # expected to be equivalent, finds the underlying object upon which they all agree and forms a\n # direct connection to it, skipping any proxies that may have been constructed by other vats\n # while transmitting the capability. See:\n # http://erights.org/elib/equality/index.html\n #\n # Note that this should only serve to bypass fully-transparent proxies -- proxies that were\n # created merely for convenience, without any intention of hiding the underlying object.\n #\n # For example, say Bob holds two capabilities hosted by Alice and Carol, but he expects that both\n # are simply proxies for a capability hosted elsewhere. He then issues a join request, which\n # operates as follows:\n # - Bob issues Join requests on both Alice and Carol. Each request contains a different piece\n # of the JoinKey.\n # - Alice is proxying a capability hosted by Dana, so forwards the request to Dana's cap.\n # - Dana receives the first request and sees that the JoinKeyPart is one of two. She notes that\n # she doesn't have the other part yet, so she records the request and responds with a\n # JoinResult.\n # - Alice relays the JoinAnswer back to Bob.\n # - Carol is also proxying a capability from Dana, and so forwards her Join request to Dana as\n # well.\n # - Dana receives Carol's request and notes that she now has both parts of a JoinKey. She\n # combines them in order to form information needed to form a secure connection to Bob. She\n # also responds with another JoinResult.\n # - Bob receives the responses from Alice and Carol. He uses the returned JoinResults to\n # determine how to connect to Dana and attempts to form the connection. Since Bob and Dana now\n # agree on a secret key that neither Alice nor Carol ever saw, this connection can be made\n # securely even if Alice or Carol is conspiring against the other. (If Alice and Carol are\n # conspiring _together_, they can obviously reproduce the key, but this doesn't matter because\n # the whole point of the join is to verify that Alice and Carol agree on what capability they\n # are proxying.)\n #\n # If the two capabilities aren't actually proxies of the same object, then the join requests\n # will come back with conflicting `hostId`s and the join will fail before attempting to form any\n # connection.\n\n questionId @0 :QuestionId;\n # Question ID used to respond to this Join. (Note that this ID only identifies one part of the\n # request for one hop; each part has a different ID and relayed copies of the request have\n # (probably) different IDs still.)\n #\n # The receiver will reply with a `Return` whose `results` is a JoinResult. This `JoinResult`\n # is relayed from the joined object's host, possibly with transformation applied as needed\n # by the network.\n #\n # Like any return, the result must be released using a `Finish`. However, this release\n # should not occur until the joiner has either successfully connected to the joined object.\n # Vats relaying a `Join` message similarly must not release the result they receive until the\n # return they relayed back towards the joiner has itself been released. This allows the\n # joined object's host to detect when the Join operation is canceled before completing -- if\n # it receives a `Finish` for one of the join results before the joiner successfully\n # connects. It can then free any resources it had allocated as part of the join.\n\n target @1 :MessageTarget;\n # The capability to join.\n\n keyPart @2 :JoinKeyPart;\n # A part of the join key. These combine to form the complete join key, which is used to establish\n # a direct connection.\n\n # TODO(before implementing): Change this so that multiple parts can be sent in a single Join\n # message, so that if multiple join parts are going to cross the same connection they can be sent\n # together, so that the receive can potentially optimize its handling of them. In the case where\n # all parts are bundled together, should the recipient be expected to simply return a cap, so\n # that the caller can immediately start pipelining to it?\n}\n\n# ========================================================================================\n# Common structures used in messages\n\nstruct MessageTarget {\n # The target of a `Call` or other messages that target a capability.\n\n union {\n importedCap @0 :ImportId;\n # This message is to a capability or promise previously imported by the caller (exported by\n # the receiver).\n\n promisedAnswer @1 :PromisedAnswer;\n # This message is to a capability that is expected to be returned by another call that has not\n # yet been completed.\n #\n # At level 0, this is supported only for addressing the result of a previous `Bootstrap`, so\n # that initial startup doesn't require a round trip.\n }\n}\n\nstruct Payload {\n # Represents some data structure that might contain capabilities.\n\n content @0 :AnyPointer;\n # Some Cap'n Proto data structure. Capability pointers embedded in this structure index into\n # `capTable`.\n\n capTable @1 :List(CapDescriptor);\n # Descriptors corresponding to the cap pointers in `content`.\n}\n\nstruct CapDescriptor {\n # **(level 1)**\n #\n # When an application-defined type contains an interface pointer, that pointer contains an index\n # into the message's capability table -- i.e. the `capTable` part of the `Payload`. Each\n # capability in the table is represented as a `CapDescriptor`. The runtime API should not reveal\n # the CapDescriptor directly to the application, but should instead wrap it in some kind of\n # callable object with methods corresponding to the interface that the capability implements.\n #\n # Keep in mind that `ExportIds` in a `CapDescriptor` are subject to reference counting. See the\n # description of `ExportId`.\n #\n # Note that it is currently not possible to include a broken capability in the CapDescriptor\n # table. Instead, create a new export (`senderPromise`) for each broken capability and then\n # immediately follow the payload-bearing Call or Return message with one Resolve message for each\n # broken capability, resolving it to an exception.\n\n union {\n none @0 :Void;\n # There is no capability here. This `CapDescriptor` should not appear in the payload content.\n # A `none` CapDescriptor can be generated when an application inserts a capability into a\n # message and then later changes its mind and removes it -- rewriting all of the other\n # capability pointers may be hard, so instead a tombstone is left, similar to the way a removed\n # struct or list instance is zeroed out of the message but the space is not reclaimed.\n # Hopefully this is unusual.\n\n senderHosted @1 :ExportId;\n # The ID of a capability in the sender's export table (receiver's import table). It may be a\n # newly allocated table entry, or an existing entry (increments the reference count).\n\n senderPromise @2 :ExportId;\n # A promise that the sender will resolve later. The sender will send exactly one Resolve\n # message at a future point in time to replace this promise. Note that even if the same\n # `senderPromise` is received multiple times, only one `Resolve` is sent to cover all of\n # them. If `senderPromise` is released before the `Resolve` is sent, the sender (of this\n # `CapDescriptor`) may choose not to send the `Resolve` at all.\n\n receiverHosted @3 :ImportId;\n # A capability (or promise) previously exported by the receiver (imported by the sender).\n\n receiverAnswer @4 :PromisedAnswer;\n # A capability expected to be returned in the results of a currently-outstanding call posed\n # by the sender.\n\n thirdPartyHosted @5 :ThirdPartyCapDescriptor;\n # **(level 3)**\n #\n # A capability that lives in neither the sender's nor the receiver's vat. The sender needs\n # to form a direct connection to a third party to pick up the capability.\n #\n # Level 1 and 2 implementations that receive a `thirdPartyHosted` may simply send calls to its\n # `vine` instead.\n }\n\n attachedFd @6 :UInt8 = 0xff;\n # If the RPC message in which this CapDescriptor was delivered also had file descriptors\n # attached, and `fd` is a valid index into the list of attached file descriptors, then\n # that file descriptor should be attached to this capability. If `attachedFd` is out-of-bounds\n # for said list, then no FD is attached.\n #\n # For example, if the RPC message arrived over a Unix socket, then file descriptors may be\n # attached by sending an SCM_RIGHTS ancillary message attached to the data bytes making up the\n # raw message. Receivers who wish to opt into FD passing should arrange to receive SCM_RIGHTS\n # whenever receiving an RPC message. Senders who wish to send FDs need not verify whether the\n # receiver knows how to receive them, because the operating system will automatically discard\n # ancillary messages like SCM_RIGHTS if the receiver doesn't ask to receive them, including\n # automatically closing any FDs.\n #\n # It is up to the application protocol to define what capabilities are expected to have file\n # descriptors attached, and what those FDs mean. But, for example, an application could use this\n # to open a file on disk and then transmit the open file descriptor to a sandboxed process that\n # does not otherwise have permission to access the filesystem directly. This is usually an\n # optimization: the sending process could instead provide an RPC interface supporting all the\n # operations needed (such as reading and writing a file), but by passing the file descriptor\n # directly, the recipient can often perform operations much more efficiently. Application\n # designers are encouraged to provide such RPC interfaces and automatically fall back to them\n # when FD passing is not available, so that the application can still work when the parties are\n # remote over a network.\n #\n # An attached FD is most often associated with a `senderHosted` descriptor. It could also make\n # sense in the case of `thirdPartyHosted`: in this case, the sender is forwarding the FD that\n # they received from the third party, so that the receiver can start using it without first\n # interacting with the third party. This is an optional optimization -- the middleman may choose\n # not to forward capabilities, in which case the receiver will need to complete the handshake\n # with the third party directly before receiving the FD. If an implementation receives a second\n # attached FD after having already received one previously (e.g. both in a `thirdPartyHosted`\n # CapDescriptor and then later again when receiving the final capability directly from the\n # third party), the implementation should discard the later FD and stick with the original. At\n # present, there is no known reason why other capability types (e.g. `receiverHosted`) would want\n # to carry an attached FD, but we reserve the right to define a meaning for this in the future.\n #\n # Each file descriptor attached to the message must be used in no more than one CapDescriptor,\n # so that the receiver does not need to use dup() or refcounting to handle the possibility of\n # multiple capabilities using the same descriptor. If multiple CapDescriptors do point to the\n # same FD index, then the receiver can arbitrarily choose which capability ends up having the\n # FD attached.\n #\n # To mitigate DoS attacks, RPC implementations should limit the number of FDs they are willing to\n # receive in a single message to a small value. If a message happens to contain more than that,\n # the list is truncated. Moreover, in some cases, FD passing needs to be blocked entirely for\n # security or implementation reasons, in which case the list may be truncated to zero. Hence,\n # `attachedFd` might point past the end of the list, which the implementation should treat as if\n # no FD was attached at all.\n #\n # The type of this field was chosen to be UInt8 because Linux supports sending only a maximum\n # of 253 file descriptors in an SCM_RIGHTS message anyway, and CapDescriptor had two bytes of\n # padding left -- so after adding this, there is still one byte for a future feature.\n # Conveniently, this also means we're able to use 0xff as the default value, which will always\n # be out-of-range (of course, the implementation should explicitly enforce that 255 descriptors\n # cannot be sent at once, rather than relying on Linux to do so).\n}\n\nstruct PromisedAnswer {\n # **(mostly level 1)**\n #\n # Specifies how to derive a promise from an unanswered question, by specifying the path of fields\n # to follow from the root of the eventual result struct to get to the desired capability. Used\n # to address method calls to a not-yet-returned capability or to pass such a capability as an\n # input to some other method call.\n #\n # Level 0 implementations must support `PromisedAnswer` only for the case where the answer is\n # to a `Bootstrap` message. In this case, `path` is always empty since `Bootstrap` always returns\n # a raw capability.\n\n questionId @0 :QuestionId;\n # ID of the question (in the sender's question table / receiver's answer table) whose answer is\n # expected to contain the capability.\n\n transform @1 :List(Op);\n # Operations / transformations to apply to the result in order to get the capability actually\n # being addressed. E.g. if the result is a struct and you want to call a method on a capability\n # pointed to by a field of the struct, you need a `getPointerField` op.\n\n struct Op {\n union {\n noop @0 :Void;\n # Does nothing. This member is mostly defined so that we can make `Op` a union even\n # though (as of this writing) only one real operation is defined.\n\n getPointerField @1 :UInt16;\n # Get a pointer field within a struct. The number is an index into the pointer section, NOT\n # a field ordinal, so that the receiver does not need to understand the schema.\n\n # TODO(someday): We could add:\n # - For lists, the ability to address every member of the list, or a slice of the list, the\n # result of which would be another list. This is useful for implementing the equivalent of\n # a SQL table join (not to be confused with the `Join` message type).\n # - Maybe some ability to test a union.\n # - Probably not a good idea: the ability to specify an arbitrary script to run on the\n # result. We could define a little stack-based language where `Op` specifies one\n # \"instruction\" or transformation to apply. Although this is not a good idea\n # (over-engineered), any narrower additions to `Op` should be designed as if this\n # were the eventual goal.\n }\n }\n}\n\nstruct ThirdPartyCapDescriptor {\n # **(level 3)**\n #\n # Identifies a capability in a third-party vat that the sender wants the receiver to pick up.\n\n id @0 :ThirdPartyCapId;\n # Identifies the third-party host and the specific capability to accept from it.\n\n vineId @1 :ExportId;\n # A proxy for the third-party object exported by the sender. In CapTP terminology this is called\n # a \"vine\", because it is an indirect reference to the third-party object that snakes through the\n # sender vat. This serves two purposes:\n #\n # * Level 1 and 2 implementations that don't understand how to connect to a third party may\n # simply send calls to the vine. Such calls will be forwarded to the third-party by the\n # sender.\n #\n # * Level 3 implementations must release the vine only once they have successfully picked up the\n # object from the third party. This ensures that the capability is not released by the sender\n # prematurely.\n #\n # The sender will close the `Provide` request that it has sent to the third party as soon as\n # it receives either a `Call` or a `Release` message directed at the vine.\n}\n\nstruct Exception {\n # **(level 0)**\n #\n # Describes an arbitrary error that prevented an operation (e.g. a call) from completing.\n #\n # Cap'n Proto exceptions always indicate that something went wrong. In other words, in a fantasy\n # world where everything always works as expected, no exceptions would ever be thrown. Clients\n # should only ever catch exceptions as a means to implement fault-tolerance, where \"fault\" can\n # mean:\n # - Bugs.\n # - Invalid input.\n # - Configuration errors.\n # - Network problems.\n # - Insufficient resources.\n # - Version skew (unimplemented functionality).\n # - Other logistical problems.\n #\n # Exceptions should NOT be used to flag application-specific conditions that a client is expected\n # to handle in an application-specific way. Put another way, in the Cap'n Proto world,\n # \"checked exceptions\" (where an interface explicitly defines the exceptions it throws and\n # clients are forced by the type system to handle those exceptions) do NOT make sense.\n\n reason @0 :Text;\n # Human-readable failure description.\n\n type @3 :Type;\n # The type of the error. The purpose of this enum is not to describe the error itself, but\n # rather to describe how the client might want to respond to the error.\n\n enum Type {\n failed @0;\n # A generic problem occurred, and it is believed that if the operation were repeated without\n # any change in the state of the world, the problem would occur again.\n #\n # A client might respond to this error by logging it for investigation by the developer and/or\n # displaying it to the user.\n\n overloaded @1;\n # The request was rejected due to a temporary lack of resources.\n #\n # Examples include:\n # - There's not enough CPU time to keep up with incoming requests, so some are rejected.\n # - The server ran out of RAM or disk space during the request.\n # - The operation timed out (took significantly longer than it should have).\n #\n # A client might respond to this error by scheduling to retry the operation much later. The\n # client should NOT retry again immediately since this would likely exacerbate the problem.\n\n disconnected @2;\n # The method failed because a connection to some necessary capability was lost.\n #\n # Examples include:\n # - The client introduced the server to a third-party capability, the connection to that third\n # party was subsequently lost, and then the client requested that the server use the dead\n # capability for something.\n # - The client previously requested that the server obtain a capability from some third party.\n # The server returned a capability to an object wrapping the third-party capability. Later,\n # the server's connection to the third party was lost.\n # - The capability has been revoked. Revocation does not necessarily mean that the client is\n # no longer authorized to use the capability; it is often used simply as a way to force the\n # client to repeat the setup process, perhaps to efficiently move them to a new back-end or\n # get them to recognize some other change that has occurred.\n #\n # A client should normally respond to this error by releasing all capabilities it is currently\n # holding related to the one it called and then re-creating them by restoring SturdyRefs and/or\n # repeating the method calls used to create them originally. In other words, disconnect and\n # start over. This should in turn cause the server to obtain a new copy of the capability that\n # it lost, thus making everything work.\n #\n # If the client receives another `disconnected` error in the process of rebuilding the\n # capability and retrying the call, it should treat this as an `overloaded` error: the network\n # is currently unreliable, possibly due to load or other temporary issues.\n\n unimplemented @3;\n # The server doesn't implement the requested method. If there is some other method that the\n # client could call (perhaps an older and/or slower interface), it should try that instead.\n # Otherwise, this should be treated like `failed`.\n }\n\n obsoleteIsCallersFault @1 :Bool;\n # OBSOLETE. Ignore.\n\n obsoleteDurability @2 :UInt16;\n # OBSOLETE. See `type` instead.\n}\n\n# ========================================================================================\n# Network-specific Parameters\n#\n# Some parts of the Cap'n Proto RPC protocol are not specified here because different vat networks\n# may wish to use different approaches to solving them. For example, on the public internet, you\n# may want to authenticate vats using public-key cryptography, but on a local intranet with trusted\n# infrastructure, you may be happy to authenticate based on network address only, or some other\n# lightweight mechanism.\n#\n# To accommodate this, we specify several \"parameter\" types. Each type is defined here as an\n# alias for `AnyPointer`, but a specific network will want to define a specific set of types to use.\n# All vats in a vat network must agree on these parameters in order to be able to communicate.\n# Inter-network communication can be accomplished through \"gateways\" that perform translation\n# between the primitives used on each network; these gateways may need to be deeply stateful,\n# depending on the translations they perform.\n#\n# For interaction over the global internet between parties with no other prior arrangement, a\n# particular set of bindings for these types is defined elsewhere. (TODO(someday): Specify where\n# these common definitions live.)\n#\n# Another common network type is the two-party network, in which one of the parties typically\n# interacts with the outside world entirely through the other party. In such a connection between\n# Alice and Bob, all objects that exist on Bob's other networks appear to Alice as if they were\n# hosted by Bob himself, and similarly all objects on Alice's network (if she even has one) appear\n# to Bob as if they were hosted by Alice. This network type is interesting because from the point\n# of view of a simple application that communicates with only one other party via the two-party\n# protocol, there are no three-party interactions at all, and joins are unusually simple to\n# implement, so implementing at level 4 is barely more complicated than implementing at level 1.\n# Moreover, if you pair an app implementing the two-party network with a container that implements\n# some other network, the app can then participate on the container's network just as if it\n# implemented that network directly. The types used by the two-party network are defined in\n# `rpc-twoparty.capnp`.\n#\n# The things that we need to parameterize are:\n# - How to store capabilities long-term without holding a connection open (mostly level 2).\n# - How to authenticate vats in three-party introductions (level 3).\n# - How to implement `Join` (level 4).\n#\n# Persistent references\n# ---------------------\n#\n# **(mostly level 2)**\n#\n# We want to allow some capabilities to be stored long-term, even if a connection is lost and later\n# recreated. ExportId is a short-term identifier that is specific to a connection, so it doesn't\n# help here. We need a way to specify long-term identifiers, as well as a strategy for\n# reconnecting to a referenced capability later.\n#\n# Three-party interactions\n# ------------------------\n#\n# **(level 3)**\n#\n# In cases where more than two vats are interacting, we have situations where VatA holds a\n# capability hosted by VatB and wants to send that capability to VatC. This can be accomplished\n# by VatA proxying requests on the new capability, but doing so has two big problems:\n# - It's inefficient, requiring an extra network hop.\n# - If VatC receives another capability to the same object from VatD, it is difficult for VatC to\n# detect that the two capabilities are really the same and to implement the E \"join\" operation,\n# which is necessary for certain four-or-more-party interactions, such as the escrow pattern.\n# See: http://www.erights.org/elib/equality/grant-matcher/index.html\n#\n# Instead, we want a way for VatC to form a direct, authenticated connection to VatB.\n#\n# Join\n# ----\n#\n# **(level 4)**\n#\n# The `Join` message type and corresponding operation arranges for a direct connection to be formed\n# between the joiner and the host of the joined object, and this connection must be authenticated.\n# Thus, the details are network-dependent.\n\nusing SturdyRef = AnyPointer;\n# **(level 2)**\n#\n# Identifies a persisted capability that can be restored in the future. How exactly a SturdyRef\n# is restored to a live object is specified along with the SturdyRef definition (i.e. not by\n# rpc.capnp).\n#\n# Generally a SturdyRef needs to specify three things:\n# - How to reach the vat that can restore the ref (e.g. a hostname or IP address).\n# - How to authenticate the vat after connecting (e.g. a public key fingerprint).\n# - The identity of a specific object hosted by the vat. Generally, this is an opaque pointer whose\n# format is defined by the specific vat -- the client has no need to inspect the object ID.\n# It is important that the object ID be unguessable if the object is not public (and objects\n# should almost never be public).\n#\n# The above are only suggestions. Some networks might work differently. For example, a private\n# network might employ a special restorer service whose sole purpose is to restore SturdyRefs.\n# In this case, the entire contents of SturdyRef might be opaque, because they are intended only\n# to be forwarded to the restorer service.\n\nusing ProvisionId = AnyPointer;\n# **(level 3)**\n#\n# The information that must be sent in an `Accept` message to identify the object being accepted.\n#\n# In a network where each vat has a public/private key pair, this could simply be the public key\n# fingerprint of the provider vat along with a nonce matching the one in the `RecipientId` used\n# in the `Provide` message sent from that provider.\n\nusing RecipientId = AnyPointer;\n# **(level 3)**\n#\n# The information that must be sent in a `Provide` message to identify the recipient of the\n# capability.\n#\n# In a network where each vat has a public/private key pair, this could simply be the public key\n# fingerprint of the recipient along with a nonce matching the one in the `ProvisionId`.\n#\n# As another example, when communicating between processes on the same machine over Unix sockets,\n# RecipientId could simply refer to a file descriptor attached to the message via SCM_RIGHTS.\n# This file descriptor would be one end of a newly-created socketpair, with the other end having\n# been sent to the capability's recipient in ThirdPartyCapId.\n\nusing ThirdPartyCapId = AnyPointer;\n# **(level 3)**\n#\n# The information needed to connect to a third party and accept a capability from it.\n#\n# In a network where each vat has a public/private key pair, this could be a combination of the\n# third party's public key fingerprint, hints on how to connect to the third party (e.g. an IP\n# address), and the nonce used in the corresponding `Provide` message's `RecipientId` as sent\n# to that third party (used to identify which capability to pick up).\n#\n# As another example, when communicating between processes on the same machine over Unix sockets,\n# ThirdPartyCapId could simply refer to a file descriptor attached to the message via SCM_RIGHTS.\n# This file descriptor would be one end of a newly-created socketpair, with the other end having\n# been sent to the process hosting the capability in RecipientId.\n\nusing JoinKeyPart = AnyPointer;\n# **(level 4)**\n#\n# A piece of a secret key. One piece is sent along each path that is expected to lead to the same\n# place. Once the pieces are combined, a direct connection may be formed between the sender and\n# the receiver, bypassing any men-in-the-middle along the paths. See the `Join` message type.\n#\n# The motivation for Joins is discussed under \"Supporting Equality\" in the \"Unibus\" protocol\n# sketch: http://www.erights.org/elib/distrib/captp/unibus.html\n#\n# In a network where each vat has a public/private key pair and each vat forms no more than one\n# connection to each other vat, Joins will rarely -- perhaps never -- be needed, as objects never\n# need to be transparently proxied and references to the same object sent over the same connection\n# have the same export ID. Thus, a successful join requires only checking that the two objects\n# come from the same connection and have the same ID, and then completes immediately.\n#\n# However, in networks where two vats may form more than one connection between each other, or\n# where proxying of objects occurs, joins are necessary.\n#\n# Typically, each JoinKeyPart would include a fixed-length data value such that all value parts\n# XOR'd together forms a shared secret that can be used to form an encrypted connection between\n# the joiner and the joined object's host. Each JoinKeyPart should also include an indication of\n# how many parts to expect and a hash of the shared secret (used to match up parts).\n\nusing JoinResult = AnyPointer;\n# **(level 4)**\n#\n# Information returned as the result to a `Join` message, needed by the joiner in order to form a\n# direct connection to a joined object. This might simply be the address of the joined object's\n# host vat, since the `JoinKey` has already been communicated so the two vats already have a shared\n# secret to use to authenticate each other.\n#\n# The `JoinResult` should also contain information that can be used to detect when the Join\n# requests ended up reaching different objects, so that this situation can be detected easily.\n# This could be a simple matter of including a sequence number -- if the joiner receives two\n# `JoinResult`s with sequence number 0, then they must have come from different objects and the\n# whole join is a failure.\n\n# ========================================================================================\n# Network interface sketch\n#\n# The interfaces below are meant to be pseudo-code to illustrate how the details of a particular\n# vat network might be abstracted away. They are written like Cap'n Proto interfaces, but in\n# practice you'd probably define these interfaces manually in the target programming language. A\n# Cap'n Proto RPC implementation should be able to use these interfaces without knowing the\n# definitions of the various network-specific parameters defined above.\n\n# interface VatNetwork {\n# # Represents a vat network, with the ability to connect to particular vats and receive\n# # connections from vats.\n# #\n# # Note that methods returning a `Connection` may return a pre-existing `Connection`, and the\n# # caller is expected to find and share state with existing users of the connection.\n#\n# # Level 0 features -----------------------------------------------\n#\n# connect(vatId :VatId) :Connection;\n# # Connect to the given vat. The transport should return a promise that does not\n# # resolve until authentication has completed, but allows messages to be pipelined in before\n# # that; the transport either queues these messages until authenticated, or sends them encrypted\n# # such that only the authentic vat would be able to decrypt them. The latter approach avoids a\n# # round trip for authentication.\n#\n# accept() :Connection;\n# # Wait for the next incoming connection and return it. Only connections formed by\n# # connect() are returned by this method.\n#\n# # Level 4 features -----------------------------------------------\n#\n# newJoiner(count :UInt32) :NewJoinerResponse;\n# # Prepare a new Join operation, which will eventually lead to forming a new direct connection\n# # to the host of the joined capability. `count` is the number of capabilities to join.\n#\n# struct NewJoinerResponse {\n# joinKeyParts :List(JoinKeyPart);\n# # Key parts to send in Join messages to each capability.\n#\n# joiner :Joiner;\n# # Used to establish the final connection.\n# }\n#\n# interface Joiner {\n# addJoinResult(result :JoinResult) :Void;\n# # Add a JoinResult received in response to one of the `Join` messages. All `JoinResult`s\n# # returned from all paths must be added before trying to connect.\n#\n# connect() :ConnectionAndProvisionId;\n# # Try to form a connection to the joined capability's host, verifying that it has received\n# # all of the JoinKeyParts. Once the connection is formed, the caller should send an `Accept`\n# # message on it with the specified `ProvisionId` in order to receive the final capability.\n# }\n#\n# acceptConnectionFromJoiner(parts :List(JoinKeyPart), paths :List(VatPath))\n# :ConnectionAndProvisionId;\n# # Called on a joined capability's host to receive the connection from the joiner, once all\n# # key parts have arrived. The caller should expect to receive an `Accept` message over the\n# # connection with the given ProvisionId.\n# }\n#\n# interface Connection {\n# # Level 0 features -----------------------------------------------\n#\n# send(message :Message) :Void;\n# # Send the message. Returns successfully when the message (and all preceding messages) has\n# # been acknowledged by the recipient.\n#\n# receive() :Message;\n# # Receive the next message, and acknowledges receipt to the sender. Messages are received in\n# # the order in which they are sent.\n#\n# # Level 3 features -----------------------------------------------\n#\n# introduceTo(recipient :Connection) :IntroductionInfo;\n# # Call before starting a three-way introduction, assuming a `Provide` message is to be sent on\n# # this connection and a `ThirdPartyCapId` is to be sent to `recipient`.\n#\n# struct IntroductionInfo {\n# sendToRecipient :ThirdPartyCapId;\n# sendToTarget :RecipientId;\n# }\n#\n# connectToIntroduced(capId :ThirdPartyCapId) :ConnectionAndProvisionId;\n# # Given a ThirdPartyCapId received over this connection, connect to the third party. The\n# # caller should then send an `Accept` message over the new connection.\n#\n# acceptIntroducedConnection(recipientId :RecipientId) :Connection;\n# # Given a RecipientId received in a `Provide` message on this `Connection`, wait for the\n# # recipient to connect, and return the connection formed. Usually, the first message received\n# # on the new connection will be an `Accept` message.\n# }\n#\n# struct ConnectionAndProvisionId {\n# # **(level 3)**\n#\n# connection :Connection;\n# # Connection on which to issue `Accept` message.\n#\n# provision :ProvisionId;\n# # `ProvisionId` to send in the `Accept` message.\n# }\n"),
"capnp/schema.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\nusing Cxx = import \"/capnp/c++.capnp\";\n\n@0xa93fc509624c72d9;\n$Cxx.namespace(\"capnp::schema\");\n\nusing Id = UInt64;\n# The globally-unique ID of a file, type, or annotation.\n\nstruct Node {\n id @0 :Id;\n\n displayName @1 :Text;\n # Name to present to humans to identify this Node. You should not attempt to parse this. Its\n # format could change. It is not guaranteed to be unique.\n #\n # (On Zooko's triangle, this is the node's nickname.)\n\n displayNamePrefixLength @2 :UInt32;\n # If you want a shorter version of `displayName` (just naming this node, without its surrounding\n # scope), chop off this many characters from the beginning of `displayName`.\n\n scopeId @3 :Id;\n # ID of the lexical parent node. Typically, the scope node will have a NestedNode pointing back\n # at this node, but robust code should avoid relying on this (and, in fact, group nodes are not\n # listed in the outer struct's nestedNodes, since they are listed in the fields). `scopeId` is\n # zero if the node has no parent, which is normally only the case with files, but should be\n # allowed for any kind of node (in order to make runtime type generation easier).\n\n parameters @32 :List(Parameter);\n # If this node is parameterized (generic), the list of parameters. Empty for non-generic types.\n\n isGeneric @33 :Bool;\n # True if this node is generic, meaning that it or one of its parent scopes has a non-empty\n # `parameters`.\n\n struct Parameter {\n # Information about one of the node's parameters.\n\n name @0 :Text;\n }\n\n nestedNodes @4 :List(NestedNode);\n # List of nodes nested within this node, along with the names under which they were declared.\n\n struct NestedNode {\n name @0 :Text;\n # Unqualified symbol name. Unlike Node.displayName, this *can* be used programmatically.\n #\n # (On Zooko's triangle, this is the node's petname according to its parent scope.)\n\n id @1 :Id;\n # ID of the nested node. Typically, the target node's scopeId points back to this node, but\n # robust code should avoid relying on this.\n }\n\n annotations @5 :List(Annotation);\n # Annotations applied to this node.\n\n union {\n # Info specific to each kind of node.\n\n file @6 :Void;\n\n struct :group {\n dataWordCount @7 :UInt16;\n # Size of the data section, in words.\n\n pointerCount @8 :UInt16;\n # Size of the pointer section, in pointers (which are one word each).\n\n preferredListEncoding @9 :ElementSize;\n # The preferred element size to use when encoding a list of this struct. If this is anything\n # other than `inlineComposite` then the struct is one word or less in size and is a candidate\n # for list packing optimization.\n\n isGroup @10 :Bool;\n # If true, then this \"struct\" node is actually not an independent node, but merely represents\n # some named union or group within a particular parent struct. This node's scopeId refers\n # to the parent struct, which may itself be a union/group in yet another struct.\n #\n # All group nodes share the same dataWordCount and pointerCount as the top-level\n # struct, and their fields live in the same ordinal and offset spaces as all other fields in\n # the struct.\n #\n # Note that a named union is considered a special kind of group -- in fact, a named union\n # is exactly equivalent to a group that contains nothing but an unnamed union.\n\n discriminantCount @11 :UInt16;\n # Number of fields in this struct which are members of an anonymous union, and thus may\n # overlap. If this is non-zero, then a 16-bit discriminant is present indicating which\n # of the overlapping fields is active. This can never be 1 -- if it is non-zero, it must be\n # two or more.\n #\n # Note that the fields of an unnamed union are considered fields of the scope containing the\n # union -- an unnamed union is not its own group. So, a top-level struct may contain a\n # non-zero discriminant count. Named unions, on the other hand, are equivalent to groups\n # containing unnamed unions. So, a named union has its own independent schema node, with\n # `isGroup` = true.\n\n discriminantOffset @12 :UInt32;\n # If `discriminantCount` is non-zero, this is the offset of the union discriminant, in\n # multiples of 16 bits.\n\n fields @13 :List(Field);\n # Fields defined within this scope (either the struct's top-level fields, or the fields of\n # a particular group; see `isGroup`).\n #\n # The fields are sorted by ordinal number, but note that because groups share the same\n # ordinal space, the field's index in this list is not necessarily exactly its ordinal.\n # On the other hand, the field's position in this list does remain the same even as the\n # protocol evolves, since it is not possible to insert or remove an earlier ordinal.\n # Therefore, for most use cases, if you want to identify a field by number, it may make the\n # most sense to use the field's index in this list rather than its ordinal.\n }\n\n enum :group {\n enumerants@14 :List(Enumerant);\n # Enumerants ordered by numeric value (ordinal).\n }\n\n interface :group {\n methods @15 :List(Method);\n # Methods ordered by ordinal.\n\n superclasses @31 :List(Superclass);\n # Superclasses of this interface.\n }\n\n const :group {\n type @16 :Type;\n value @17 :Value;\n }\n\n annotation :group {\n type @18 :Type;\n\n targetsFile @19 :Bool;\n targetsConst @20 :Bool;\n targetsEnum @21 :Bool;\n targetsEnumerant @22 :Bool;\n targetsStruct @23 :Bool;\n targetsField @24 :Bool;\n targetsUnion @25 :Bool;\n targetsGroup @26 :Bool;\n targetsInterface @27 :Bool;\n targetsMethod @28 :Bool;\n targetsParam @29 :Bool;\n targetsAnnotation @30 :Bool;\n }\n }\n\n struct SourceInfo {\n # Additional information about a node which is not needed at runtime, but may be useful for\n # documentation or debugging purposes. This is kept in a separate struct to make sure it\n # doesn't accidentally get included in contexts where it is not needed. The\n # `CodeGeneratorRequest` includes this information in a separate array.\n\n id @0 :Id;\n # ID of the Node which this info describes.\n\n docComment @1 :Text;\n # The top-level doc comment for the Node.\n\n members @2 :List(Member);\n # Information about each member -- i.e. fields (for structs), enumerants (for enums), or\n # methods (for interfaces).\n #\n # This list is the same length and order as the corresponding list in the Node, i.e.\n # Node.struct.fields, Node.enum.enumerants, or Node.interface.methods.\n\n struct Member {\n docComment @0 :Text;\n # Doc comment on the member.\n }\n\n # TODO(someday): Record location of the declaration in the original source code.\n }\n}\n\nstruct Field {\n # Schema for a field of a struct.\n\n name @0 :Text;\n\n codeOrder @1 :UInt16;\n # Indicates where this member appeared in the code, relative to other members.\n # Code ordering may have semantic relevance -- programmers tend to place related fields\n # together. So, using code ordering makes sense in human-readable formats where ordering is\n # otherwise irrelevant, like JSON. The values of codeOrder are tightly-packed, so the maximum\n # value is count(members) - 1. Fields that are members of a union are only ordered relative to\n # the other members of that union, so the maximum value there is count(union.members).\n\n annotations @2 :List(Annotation);\n\n const noDiscriminant :UInt16 = 0xffff;\n\n discriminantValue @3 :UInt16 = Field.noDiscriminant;\n # If the field is in a union, this is the value which the union's discriminant should take when\n # the field is active. If the field is not in a union, this is 0xffff.\n\n union {\n slot :group {\n # A regular, non-group, non-fixed-list field.\n\n offset @4 :UInt32;\n # Offset, in units of the field's size, from the beginning of the section in which the field\n # resides. E.g. for a UInt32 field, multiply this by 4 to get the byte offset from the\n # beginning of the data section.\n\n type @5 :Type;\n defaultValue @6 :Value;\n\n hadExplicitDefault @10 :Bool;\n # Whether the default value was specified explicitly. Non-explicit default values are always\n # zero or empty values. Usually, whether the default value was explicit shouldn't matter.\n # The main use case for this flag is for structs representing method parameters:\n # explicitly-defaulted parameters may be allowed to be omitted when calling the method.\n }\n\n group :group {\n # A group.\n\n typeId @7 :Id;\n # The ID of the group's node.\n }\n }\n\n ordinal :union {\n implicit @8 :Void;\n explicit @9 :UInt16;\n # The original ordinal number given to the field. You probably should NOT use this; if you need\n # a numeric identifier for a field, use its position within the field array for its scope.\n # The ordinal is given here mainly just so that the original schema text can be reproduced given\n # the compiled version -- i.e. so that `capnp compile -ocapnp` can do its job.\n }\n}\n\nstruct Enumerant {\n # Schema for member of an enum.\n\n name @0 :Text;\n\n codeOrder @1 :UInt16;\n # Specifies order in which the enumerants were declared in the code.\n # Like Struct.Field.codeOrder.\n\n annotations @2 :List(Annotation);\n}\n\nstruct Superclass {\n id @0 :Id;\n brand @1 :Brand;\n}\n\nstruct Method {\n # Schema for method of an interface.\n\n name @0 :Text;\n\n codeOrder @1 :UInt16;\n # Specifies order in which the methods were declared in the code.\n # Like Struct.Field.codeOrder.\n\n implicitParameters @7 :List(Node.Parameter);\n # The parameters listed in [] (typically, type / generic parameters), whose bindings are intended\n # to be inferred rather than specified explicitly, although not all languages support this.\n\n paramStructType @2 :Id;\n # ID of the parameter struct type. If a named parameter list was specified in the method\n # declaration (rather than a single struct parameter type) then a corresponding struct type is\n # auto-generated. Such an auto-generated type will not be listed in the interface's\n # `nestedNodes` and its `scopeId` will be zero -- it is completely detached from the namespace.\n # (Awkwardly, it does of course inherit generic parameters from the method's scope, which makes\n # this a situation where you can't just climb the scope chain to find where a particular\n # generic parameter was introduced. Making the `scopeId` zero was a mistake.)\n\n paramBrand @5 :Brand;\n # Brand of param struct type.\n\n resultStructType @3 :Id;\n # ID of the return struct type; similar to `paramStructType`.\n\n resultBrand @6 :Brand;\n # Brand of result struct type.\n\n annotations @4 :List(Annotation);\n}\n\nstruct Type {\n # Represents a type expression.\n\n union {\n # The ordinals intentionally match those of Value.\n\n void @0 :Void;\n bool @1 :Void;\n int8 @2 :Void;\n int16 @3 :Void;\n int32 @4 :Void;\n int64 @5 :Void;\n uint8 @6 :Void;\n uint16 @7 :Void;\n uint32 @8 :Void;\n uint64 @9 :Void;\n float32 @10 :Void;\n float64 @11 :Void;\n text @12 :Void;\n data @13 :Void;\n\n list :group {\n elementType @14 :Type;\n }\n\n enum :group {\n typeId @15 :Id;\n brand @21 :Brand;\n }\n struct :group {\n typeId @16 :Id;\n brand @22 :Brand;\n }\n interface :group {\n typeId @17 :Id;\n brand @23 :Brand;\n }\n\n anyPointer :union {\n unconstrained :union {\n # A regular AnyPointer.\n #\n # The name \"unconstrained\" means as opposed to constraining it to match a type parameter.\n # In retrospect this name is probably a poor choice given that it may still be constrained\n # to be a struct, list, or capability.\n\n anyKind @18 :Void; # truly AnyPointer\n struct @25 :Void; # AnyStruct\n list @26 :Void; # AnyList\n capability @27 :Void; # Capability\n }\n\n parameter :group {\n # This is actually a reference to a type parameter defined within this scope.\n\n scopeId @19 :Id;\n # ID of the generic type whose parameter we're referencing. This should be a parent of the\n # current scope.\n\n parameterIndex @20 :UInt16;\n # Index of the parameter within the generic type's parameter list.\n }\n\n implicitMethodParameter :group {\n # This is actually a reference to an implicit (generic) parameter of a method. The only\n # legal context for this type to appear is inside Method.paramBrand or Method.resultBrand.\n\n parameterIndex @24 :UInt16;\n }\n }\n }\n}\n\nstruct Brand {\n # Specifies bindings for parameters of generics. Since these bindings turn a generic into a\n # non-generic, we call it the \"brand\".\n\n scopes @0 :List(Scope);\n # For each of the target type and each of its parent scopes, a parameterization may be included\n # in this list. If no parameterization is included for a particular relevant scope, then either\n # that scope has no parameters or all parameters should be considered to be `AnyPointer`.\n\n struct Scope {\n scopeId @0 :Id;\n # ID of the scope to which these params apply.\n\n union {\n bind @1 :List(Binding);\n # List of parameter bindings.\n\n inherit @2 :Void;\n # The place where this Brand appears is actually within this scope or a sub-scope,\n # and the bindings for this scope should be inherited from the reference point.\n }\n }\n\n struct Binding {\n union {\n unbound @0 :Void;\n type @1 :Type;\n\n # TODO(someday): Allow non-type parameters? Unsure if useful.\n }\n }\n}\n\nstruct Value {\n # Represents a value, e.g. a field default value, constant value, or annotation value.\n\n union {\n # The ordinals intentionally match those of Type.\n\n void @0 :Void;\n bool @1 :Bool;\n int8 @2 :Int8;\n int16 @3 :Int16;\n int32 @4 :Int32;\n int64 @5 :Int64;\n uint8 @6 :UInt8;\n uint16 @7 :UInt16;\n uint32 @8 :UInt32;\n uint64 @9 :UInt64;\n float32 @10 :Float32;\n float64 @11 :Float64;\n text @12 :Text;\n data @13 :Data;\n\n list @14 :AnyPointer;\n\n enum @15 :UInt16;\n struct @16 :AnyPointer;\n\n interface @17 :Void;\n # The only interface value that can be represented statically is \"null\", whose methods always\n # throw exceptions.\n\n anyPointer @18 :AnyPointer;\n }\n}\n\nstruct Annotation {\n # Describes an annotation applied to a declaration. Note AnnotationNode describes the\n # annotation's declaration, while this describes a use of the annotation.\n\n id @0 :Id;\n # ID of the annotation node.\n\n brand @2 :Brand;\n # Brand of the annotation.\n #\n # Note that the annotation itself is not allowed to be parameterized, but its scope might be.\n\n value @1 :Value;\n}\n\nenum ElementSize {\n # Possible element sizes for encoded lists. These correspond exactly to the possible values of\n # the 3-bit element size component of a list pointer.\n\n empty @0; # aka \"void\", but that's a keyword.\n bit @1;\n byte @2;\n twoBytes @3;\n fourBytes @4;\n eightBytes @5;\n pointer @6;\n inlineComposite @7;\n}\n\nstruct CapnpVersion {\n major @0 :UInt16;\n minor @1 :UInt8;\n micro @2 :UInt8;\n}\n\nstruct CodeGeneratorRequest {\n capnpVersion @2 :CapnpVersion;\n # Version of the `capnp` executable. Generally, code generators should ignore this, but the code\n # generators that ship with `capnp` itself will print a warning if this mismatches since that\n # probably indicates something is misconfigured.\n #\n # The first version of 'capnp' to set this was 0.6.0. So, if it's missing, the compiler version\n # is older than that.\n\n nodes @0 :List(Node);\n # All nodes parsed by the compiler, including for the files on the command line and their\n # imports.\n\n sourceInfo @3 :List(Node.SourceInfo);\n # Information about the original source code for each node, where available. This array may be\n # omitted or may be missing some nodes if no info is available for them.\n\n requestedFiles @1 :List(RequestedFile);\n # Files which were listed on the command line.\n\n struct RequestedFile {\n id @0 :Id;\n # ID of the file.\n\n filename @1 :Text;\n # Name of the file as it appeared on the command-line (minus the src-prefix). You may use\n # this to decide where to write the output.\n\n imports @2 :List(Import);\n # List of all imported paths seen in this file.\n\n struct Import {\n id @0 :Id;\n # ID of the imported file.\n\n name @1 :Text;\n # Name which *this* file used to refer to the foreign file. This may be a relative name.\n # This information is provided because it might be useful for code generation, e.g. to\n # generate #include directives in C++. We don't put this in Node.file because this\n # information is only meaningful at compile time anyway.\n #\n # (On Zooko's triangle, this is the import's petname according to the importing file.)\n }\n }\n}\n"),
"capnp/stream.capnp": []byte("# Copyright (c) 2019 Cloudflare, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\n@0x86c366a91393f3f8;\n# Defines placeholder types used to provide backwards-compatibility while introducing streaming\n# to the language. The goal is that old code generators that don't know about streaming can still\n# generate code that functions, leaving it up to the application to implement flow control\n# manually.\n\n$import \"/capnp/c++.capnp\".namespace(\"capnp\");\n\nstruct StreamResult @0x995f9a3377c0b16e {\n # Empty struct that serves as the return type for \"streaming\" methods.\n #\n # Defining a method like:\n #\n # write @0 (bytes :Data) -> stream;\n #\n # Is equivalent to:\n #\n # write @0 (bytes :Data) -> import \"/capnp/stream.capnp\".StreamResult;\n #\n # However, implementations that recognize streaming will elide the reference to StreamResult\n # and instead give write() a different signature appropriate for streaming.\n #\n # Streaming methods do not return a result -- that is, they return Promise<void>. This promise\n # resolves not to indicate that the call was actually delivered, but instead to provide\n # backpressure. When the previous call's promise resolves, it is time to make another call. On\n # the client side, the RPC system will resolve promises immediately until an appropriate number\n # of requests are in-flight, and then will delay promise resolution to apply back-pressure.\n # On the server side, the RPC system will deliver one call at a time.\n}\n"),
"capnp/test-import.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\n@0xf36d7b330303c66e;\n\nusing Test = import \"test.capnp\";\n\nstruct TestImport {\n field @0 :Test.TestAllTypes;\n}\n"),
"capnp/test-import2.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\n@0xc64a3bf0338a124a;\n\nusing Import1 = import \"/capnp/schema.capnp\";\nusing Import2 = import \"test-import.capnp\";\nusing Import3 = import \"test.capnp\";\n\nstruct TestImport2 {\n foo @0 :Import3.TestAllTypes;\n bar @1 :Import1.Node;\n baz @2 :Import2.TestImport;\n}\n"),
"capnp/test.capnp": []byte("# Copyright (c) 2013-2014 Sandstorm Development Group, Inc. and contributors\n# Licensed under the MIT License:\n#\n# Permission is hereby granted, free of charge, to any person obtaining a copy\n# of this software and associated documentation files (the \"Software\"), to deal\n# in the Software without restriction, including without limitation the rights\n# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n# copies of the Software, and to permit persons to whom the Software is\n# furnished to do so, subject to the following conditions:\n#\n# The above copyright notice and this permission notice shall be included in\n# all copies or substantial portions of the Software.\n#\n# THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\n# THE SOFTWARE.\n\n@0xd508eebdc2dc42b8;\n\nusing Cxx = import \"c++.capnp\";\n\n# Use a namespace likely to cause trouble if the generated code doesn't use fully-qualified\n# names for stuff in the capnproto namespace.\n$Cxx.namespace(\"capnproto_test::capnp::test\");\n\nenum TestEnum {\n foo @0;\n bar @1;\n baz @2;\n qux @3;\n quux @4;\n corge @5;\n grault @6;\n garply @7;\n}\n\nstruct TestAllTypes {\n voidField @0 : Void;\n boolField @1 : Bool;\n int8Field @2 : Int8;\n int16Field @3 : Int16;\n int32Field @4 : Int32;\n int64Field @5 : Int64;\n uInt8Field @6 : UInt8;\n uInt16Field @7 : UInt16;\n uInt32Field @8 : UInt32;\n uInt64Field @9 : UInt64;\n float32Field @10 : Float32;\n float64Field @11 : Float64;\n textField @12 : Text;\n dataField @13 : Data;\n structField @14 : TestAllTypes;\n enumField @15 : TestEnum;\n interfaceField @16 : Void; # TODO\n\n voidList @17 : List(Void);\n boolList @18 : List(Bool);\n int8List @19 : List(Int8);\n int16List @20 : List(Int16);\n int32List @21 : List(Int32);\n int64List @22 : List(Int64);\n uInt8List @23 : List(UInt8);\n uInt16List @24 : List(UInt16);\n uInt32List @25 : List(UInt32);\n uInt64List @26 : List(UInt64);\n float32List @27 : List(Float32);\n float64List @28 : List(Float64);\n textList @29 : List(Text);\n dataList @30 : List(Data);\n structList @31 : List(TestAllTypes);\n enumList @32 : List(TestEnum);\n interfaceList @33 : List(Void); # TODO\n}\n\nstruct TestDefaults {\n voidField @0 : Void = void;\n boolField @1 : Bool = true;\n int8Field @2 : Int8 = -123;\n int16Field @3 : Int16 = -12345;\n int32Field @4 : Int32 = -12345678;\n int64Field @5 : Int64 = -123456789012345;\n uInt8Field @6 : UInt8 = 234;\n uInt16Field @7 : UInt16 = 45678;\n uInt32Field @8 : UInt32 = 3456789012;\n uInt64Field @9 : UInt64 = 12345678901234567890;\n float32Field @10 : Float32 = 1234.5;\n float64Field @11 : Float64 = -123e45;\n textField @12 : Text = \"foo\";\n dataField @13 : Data = 0x\"62 61 72\"; # \"bar\"\n structField @14 : TestAllTypes = (\n voidField = void,\n boolField = true,\n int8Field = -12,\n int16Field = 3456,\n int32Field = -78901234,\n int64Field = 56789012345678,\n uInt8Field = 90,\n uInt16Field = 1234,\n uInt32Field = 56789012,\n uInt64Field = 345678901234567890,\n float32Field = -1.25e-10,\n float64Field = 345,\n textField = \"baz\",\n dataField = \"qux\",\n structField = (\n textField = \"nested\",\n structField = (textField = \"really nested\")),\n enumField = baz,\n # interfaceField can't have a default\n\n voidList = [void, void, void],\n boolList = [false, true, false, true, true],\n int8List = [12, -34, -0x80, 0x7f],\n int16List = [1234, -5678, -0x8000, 0x7fff],\n int32List = [12345678, -90123456, -0x80000000, 0x7fffffff],\n int64List = [123456789012345, -678901234567890, -0x8000000000000000, 0x7fffffffffffffff],\n uInt8List = [12, 34, 0, 0xff],\n uInt16List = [1234, 5678, 0, 0xffff],\n uInt32List = [12345678, 90123456, 0, 0xffffffff],\n uInt64List = [123456789012345, 678901234567890, 0, 0xffffffffffffffff],\n float32List = [0, 1234567, 1e37, -1e37, 1e-37, -1e-37],\n float64List = [0, 123456789012345, 1e306, -1e306, 1e-306, -1e-306],\n textList = [\"quux\", \"corge\", \"grault\"],\n dataList = [\"garply\", \"waldo\", \"fred\"],\n structList = [\n (textField = \"x \" \"structlist\"\n \" 1\"),\n (textField = \"x structlist 2\"),\n (textField = \"x structlist 3\")],\n enumList = [qux, bar, grault]\n # interfaceList can't have a default\n );\n enumField @15 : TestEnum = corge;\n interfaceField @16 : Void; # TODO\n\n voidList @17 : List(Void) = [void, void, void, void, void, void];\n boolList @18 : List(Bool) = [true, false, false, true];\n int8List @19 : List(Int8) = [111, -111];\n int16List @20 : List(Int16) = [11111, -11111];\n int32List @21 : List(Int32) = [111111111, -111111111];\n int64List @22 : List(Int64) = [1111111111111111111, -1111111111111111111];\n uInt8List @23 : List(UInt8) = [111, 222] ;\n uInt16List @24 : List(UInt16) = [33333, 44444];\n uInt32List @25 : List(UInt32) = [3333333333];\n uInt64List @26 : List(UInt64) = [11111111111111111111];\n float32List @27 : List(Float32) = [5555.5, inf, -inf, nan];\n float64List @28 : List(Float64) = [7777.75, inf, -inf, nan];\n textList @29 : List(Text) = [\"plugh\", \"xyzzy\", \"thud\"];\n dataList @30 : List(Data) = [\"oops\", \"exhausted\", \"rfc3092\"];\n structList @31 : List(TestAllTypes) = [\n (textField = \"structlist 1\"),\n (textField = \"structlist 2\"),\n (textField = \"structlist 3\")];\n enumList @32 : List(TestEnum) = [foo, garply];\n interfaceList @33 : List(Void); # TODO\n}\n\nstruct TestAnyPointer {\n anyPointerField @0 :AnyPointer;\n\n # Do not add any other fields here! Some tests rely on anyPointerField being the last pointer\n # in the struct.\n}\n\nstruct TestAnyOthers {\n anyStructField @0 :AnyStruct;\n anyListField @1 :AnyList;\n capabilityField @2 :Capability;\n}\n\nstruct TestOutOfOrder {\n foo @3 :Text;\n bar @2 :Text;\n baz @8 :Text;\n qux @0 :Text;\n quux @6 :Text;\n corge @4 :Text;\n grault @1 :Text;\n garply @7 :Text;\n waldo @5 :Text;\n}\n\nstruct TestUnion {\n union0 @0! :union {\n # Pack union 0 under ideal conditions: there is no unused padding space prior to it.\n u0f0s0 @4: Void;\n u0f0s1 @5: Bool;\n u0f0s8 @6: Int8;\n u0f0s16 @7: Int16;\n u0f0s32 @8: Int32;\n u0f0s64 @9: Int64;\n u0f0sp @10: Text;\n\n # Pack more stuff into union0 -- should go in same space.\n u0f1s0 @11: Void;\n u0f1s1 @12: Bool;\n u0f1s8 @13: Int8;\n u0f1s16 @14: Int16;\n u0f1s32 @15: Int32;\n u0f1s64 @16: Int64;\n u0f1sp @17: Text;\n }\n\n # Pack one bit in order to make pathological situation for union1.\n bit0 @18: Bool;\n\n union1 @1! :union {\n # Pack pathologically bad case. Each field takes up new space.\n u1f0s0 @19: Void;\n u1f0s1 @20: Bool;\n u1f1s1 @21: Bool;\n u1f0s8 @22: Int8;\n u1f1s8 @23: Int8;\n u1f0s16 @24: Int16;\n u1f1s16 @25: Int16;\n u1f0s32 @26: Int32;\n u1f1s32 @27: Int32;\n u1f0s64 @28: Int64;\n u1f1s64 @29: Int64;\n u1f0sp @30: Text;\n u1f1sp @31: Text;\n\n # Pack more stuff into union1 -- each should go into the same space as corresponding u1f0s*.\n u1f2s0 @32: Void;\n u1f2s1 @33: Bool;\n u1f2s8 @34: Int8;\n u1f2s16 @35: Int16;\n u1f2s32 @36: Int32;\n u1f2s64 @37: Int64;\n u1f2sp @38: Text;\n }\n\n # Fill in the rest of that bitfield from earlier.\n bit2 @39: Bool;\n bit3 @40: Bool;\n bit4 @41: Bool;\n bit5 @42: Bool;\n bit6 @43: Bool;\n bit7 @44: Bool;\n\n # Interleave two unions to be really annoying.\n # Also declare in reverse order to make sure union discriminant values are sorted by field number\n # and not by declaration order.\n union2 @2! :union {\n u2f0s64 @54: Int64;\n u2f0s32 @52: Int32;\n u2f0s16 @50: Int16;\n u2f0s8 @47: Int8;\n u2f0s1 @45: Bool;\n }\n\n union3 @3! :union {\n u3f0s64 @55: Int64;\n u3f0s32 @53: Int32;\n u3f0s16 @51: Int16;\n u3f0s8 @48: Int8;\n u3f0s1 @46: Bool;\n }\n\n byte0 @49: UInt8;\n}\n\nstruct TestUnnamedUnion {\n before @0 :Text;\n\n union {\n foo @1 :UInt16;\n bar @3 :UInt32;\n }\n\n middle @2 :UInt16;\n\n after @4 :Text;\n}\n\nstruct TestUnionInUnion {\n # There is no reason to ever do this.\n outer :union {\n inner :union {\n foo @0 :Int32;\n bar @1 :Int32;\n }\n baz @2 :Int32;\n }\n}\n\nstruct TestGroups {\n groups :union {\n foo :group {\n corge @0 :Int32;\n grault @2 :Int64;\n garply @8 :Text;\n }\n bar :group {\n corge @3 :Int32;\n grault @4 :Text;\n garply @5 :Int64;\n }\n baz :group {\n corge @1 :Int32;\n grault @6 :Text;\n garply @7 :Text;\n }\n }\n}\n\nstruct TestInterleavedGroups {\n group1 :group {\n foo @0 :UInt32;\n bar @2 :UInt64;\n union {\n qux @4 :UInt16;\n corge :group {\n grault @6 :UInt64;\n garply @8 :UInt16;\n plugh @14 :Text;\n xyzzy @16 :Text;\n }\n\n fred @12 :Text;\n }\n\n waldo @10 :Text;\n }\n\n group2 :group {\n foo @1 :UInt32;\n bar @3 :UInt64;\n union {\n qux @5 :UInt16;\n corge :group {\n grault @7 :UInt64;\n garply @9 :UInt16;\n plugh @15 :Text;\n xyzzy @17 :Text;\n }\n\n fred @13 :Text;\n }\n\n waldo @11 :Text;\n }\n}\n\nstruct TestUnionDefaults {\n s16s8s64s8Set @0 :TestUnion =\n (union0 = (u0f0s16 = 321), union1 = (u1f0s8 = 123), union2 = (u2f0s64 = 12345678901234567),\n union3 = (u3f0s8 = 55));\n s0sps1s32Set @1 :TestUnion =\n (union0 = (u0f1s0 = void), union1 = (u1f0sp = \"foo\"), union2 = (u2f0s1 = true),\n union3 = (u3f0s32 = 12345678));\n\n unnamed1 @2 :TestUnnamedUnion = (foo = 123);\n unnamed2 @3 :TestUnnamedUnion = (bar = 321, before = \"foo\", after = \"bar\");\n}\n\nstruct TestNestedTypes {\n enum NestedEnum {\n foo @0;\n bar @1;\n }\n\n struct NestedStruct {\n enum NestedEnum {\n baz @0;\n qux @1;\n quux @2;\n }\n\n outerNestedEnum @0 :TestNestedTypes.NestedEnum = bar;\n innerNestedEnum @1 :NestedEnum = quux;\n }\n\n nestedStruct @0 :NestedStruct;\n\n outerNestedEnum @1 :NestedEnum = bar;\n innerNestedEnum @2 :NestedStruct.NestedEnum = quux;\n}\n\nstruct TestUsing {\n using OuterNestedEnum = TestNestedTypes.NestedEnum;\n using TestNestedTypes.NestedStruct.NestedEnum;\n\n outerNestedEnum @1 :OuterNestedEnum = bar;\n innerNestedEnum @0 :NestedEnum = quux;\n}\n\nstruct TestLists {\n # Small structs, when encoded as list, will be encoded as primitive lists rather than struct\n # lists, to save space.\n struct Struct0 { f @0 :Void; }\n struct Struct1 { f @0 :Bool; }\n struct Struct8 { f @0 :UInt8; }\n struct Struct16 { f @0 :UInt16; }\n struct Struct32 { f @0 :UInt32; }\n struct Struct64 { f @0 :UInt64; }\n struct StructP { f @0 :Text; }\n\n # Versions of the above which cannot be encoded as primitive lists.\n struct Struct0c { f @0 :Void; pad @1 :Text; }\n struct Struct1c { f @0 :Bool; pad @1 :Text; }\n struct Struct8c { f @0 :UInt8; pad @1 :Text; }\n struct Struct16c { f @0 :UInt16; pad @1 :Text; }\n struct Struct32c { f @0 :UInt32; pad @1 :Text; }\n struct Struct64c { f @0 :UInt64; pad @1 :Text; }\n struct StructPc { f @0 :Text; pad @1 :UInt64; }\n\n list0 @0 :List(Struct0);\n list1 @1 :List(Struct1);\n list8 @2 :List(Struct8);\n list16 @3 :List(Struct16);\n list32 @4 :List(Struct32);\n list64 @5 :List(Struct64);\n listP @6 :List(StructP);\n\n int32ListList @7 :List(List(Int32));\n textListList @8 :List(List(Text));\n structListList @9 :List(List(TestAllTypes));\n}\n\nstruct TestFieldZeroIsBit {\n bit @0 :Bool;\n secondBit @1 :Bool = true;\n thirdField @2 :UInt8 = 123;\n}\n\nstruct TestListDefaults {\n lists @0 :TestLists = (\n list0 = [(f = void), (f = void)],\n list1 = [(f = true), (f = false), (f = true), (f = true)],\n list8 = [(f = 123), (f = 45)],\n list16 = [(f = 12345), (f = 6789)],\n list32 = [(f = 123456789), (f = 234567890)],\n list64 = [(f = 1234567890123456), (f = 2345678901234567)],\n listP = [(f = \"foo\"), (f = \"bar\")],\n int32ListList = [[1, 2, 3], [4, 5], [12341234]],\n textListList = [[\"foo\", \"bar\"], [\"baz\"], [\"qux\", \"corge\"]],\n structListList = [[(int32Field = 123), (int32Field = 456)], [(int32Field = 789)]]);\n}\n\nstruct TestLateUnion {\n # Test what happens if the unions are not the first ordinals in the struct. At one point this\n # was broken for the dynamic API.\n\n foo @0 :Int32;\n bar @1 :Text;\n baz @2 :Int16;\n\n theUnion @3! :union {\n qux @4 :Text;\n corge @5 :List(Int32);\n grault @6 :Float32;\n }\n\n anotherUnion @7! :union {\n qux @8 :Text;\n corge @9 :List(Int32);\n grault @10 :Float32;\n }\n}\n\nstruct TestOldVersion {\n # A subset of TestNewVersion.\n old1 @0 :Int64;\n old2 @1 :Text;\n old3 @2 :TestOldVersion;\n}\n\nstruct TestNewVersion {\n # A superset of TestOldVersion.\n old1 @0 :Int64;\n old2 @1 :Text;\n old3 @2 :TestNewVersion;\n new1 @3 :Int64 = 987;\n new2 @4 :Text = \"baz\";\n}\n\nstruct TestOldUnionVersion {\n union {\n a @0 :Void;\n b @1 :UInt64;\n }\n}\n\nstruct TestNewUnionVersion {\n union {\n a :union {\n a0 @0 :Void;\n a1 @2 :UInt64;\n }\n b @1 :UInt64;\n }\n}\n\nstruct TestStructUnion {\n un @0! :union {\n struct @1 :SomeStruct;\n object @2 :TestAnyPointer;\n }\n\n struct SomeStruct {\n someText @0 :Text;\n moreText @1 :Text;\n }\n}\n\nstruct TestPrintInlineStructs {\n someText @0 :Text;\n\n structList @1 :List(InlineStruct);\n struct InlineStruct {\n int32Field @0 :Int32;\n textField @1 :Text;\n }\n}\n\nstruct TestWholeFloatDefault {\n # At one point, these failed to compile in C++ because it would produce literals like \"123f\",\n # which is not valid; it needs to be \"123.0f\".\n field @0 :Float32 = 123;\n bigField @1 :Float32 = 2e30;\n const constant :Float32 = 456;\n const bigConstant :Float32 = 4e30;\n}\n\nstruct TestGenerics(Foo, Bar) {\n foo @0 :Foo;\n rev @1 :TestGenerics(Bar, Foo);\n\n union {\n uv @2:Void;\n ug :group {\n ugfoo @3:Int32;\n }\n }\n\n list @4 :List(Inner);\n # At one time this failed to compile with MSVC due to poor expression SFINAE support.\n\n struct Inner {\n foo @0 :Foo;\n bar @1 :Bar;\n }\n\n struct Inner2(Baz) {\n bar @0 :Bar;\n baz @1 :Baz;\n innerBound @2 :Inner;\n innerUnbound @3 :TestGenerics.Inner;\n\n struct DeepNest(Qux) {\n foo @0 :Foo;\n bar @1 :Bar;\n baz @2 :Baz;\n qux @3 :Qux;\n\n interface DeepNestInterface(Quux) {\n # At one time this failed to compile.\n call @0 () -> ();\n }\n }\n }\n\n interface Interface(Qux) {\n call @0 Inner2(Text) -> (qux :Qux, gen :TestGenerics(TestAllTypes, TestAnyPointer));\n }\n\n annotation ann(struct) :Foo;\n\n using AliasFoo = Foo;\n using AliasInner = Inner;\n using AliasInner2 = Inner2;\n using AliasInner2Text = Inner2(Text);\n using AliasRev = TestGenerics(Bar, Foo);\n\n struct UseAliases {\n foo @0 :AliasFoo;\n inner @1 :AliasInner;\n inner2 @2 :AliasInner2;\n inner2Bind @3 :AliasInner2(Text);\n inner2Text @4 :AliasInner2Text;\n revFoo @5 :AliasRev.AliasFoo;\n }\n}\n\nstruct TestGenericsWrapper(Foo, Bar) {\n value @0 :TestGenerics(Foo, Bar);\n}\n\nstruct TestGenericsWrapper2 {\n value @0 :TestGenericsWrapper(Text, TestAllTypes);\n}\n\ninterface TestImplicitMethodParams {\n call @0 [T, U] (foo :T, bar :U) -> TestGenerics(T, U);\n}\n\ninterface TestImplicitMethodParamsInGeneric(V) {\n call @0 [T, U] (foo :T, bar :U) -> TestGenerics(T, U);\n}\n\nstruct TestGenericsUnion(Foo, Bar) {\n # At one point this failed to compile.\n\n union {\n foo @0 :Foo;\n bar @1 :Bar;\n }\n}\n\nstruct TestUseGenerics $TestGenerics(Text, Data).ann(\"foo\") {\n basic @0 :TestGenerics(TestAllTypes, TestAnyPointer);\n inner @1 :TestGenerics(TestAllTypes, TestAnyPointer).Inner;\n inner2 @2 :TestGenerics(TestAllTypes, TestAnyPointer).Inner2(Text);\n unspecified @3 :TestGenerics;\n unspecifiedInner @4 :TestGenerics.Inner2(Text);\n wrapper @8 :TestGenericsWrapper(TestAllTypes, TestAnyPointer);\n cap @18 :TestGenerics(TestInterface, Text);\n genericCap @19 :TestGenerics(TestAllTypes, List(UInt32)).Interface(Data);\n\n default @5 :TestGenerics(TestAllTypes, Text) =\n (foo = (int16Field = 123), rev = (foo = \"text\", rev = (foo = (int16Field = 321))));\n defaultInner @6 :TestGenerics(TestAllTypes, Text).Inner =\n (foo = (int16Field = 123), bar = \"text\");\n defaultUser @7 :TestUseGenerics = (basic = (foo = (int16Field = 123)));\n defaultWrapper @9 :TestGenericsWrapper(Text, TestAllTypes) =\n (value = (foo = \"text\", rev = (foo = (int16Field = 321))));\n defaultWrapper2 @10 :TestGenericsWrapper2 =\n (value = (value = (foo = \"text\", rev = (foo = (int16Field = 321)))));\n\n aliasFoo @11 :TestGenerics(TestAllTypes, TestAnyPointer).AliasFoo = (int16Field = 123);\n aliasInner @12 :TestGenerics(TestAllTypes, TestAnyPointer).AliasInner\n = (foo = (int16Field = 123));\n aliasInner2 @13 :TestGenerics(TestAllTypes, TestAnyPointer).AliasInner2\n = (innerBound = (foo = (int16Field = 123)));\n aliasInner2Bind @14 :TestGenerics(TestAllTypes, TestAnyPointer).AliasInner2(List(UInt32))\n = (baz = [12, 34], innerBound = (foo = (int16Field = 123)));\n aliasInner2Text @15 :TestGenerics(TestAllTypes, TestAnyPointer).AliasInner2Text\n = (baz = \"text\", innerBound = (foo = (int16Field = 123)));\n aliasRev @16 :TestGenerics(TestAnyPointer, Text).AliasRev.AliasFoo = \"text\";\n\n useAliases @17 :TestGenerics(TestAllTypes, List(UInt32)).UseAliases = (\n foo = (int16Field = 123),\n inner = (foo = (int16Field = 123)),\n inner2 = (innerBound = (foo = (int16Field = 123))),\n inner2Bind = (baz = \"text\", innerBound = (foo = (int16Field = 123))),\n inner2Text = (baz = \"text\", innerBound = (foo = (int16Field = 123))),\n revFoo = [12, 34, 56]);\n}\n\nstruct TestEmptyStruct {}\n\nstruct TestConstants {\n const voidConst :Void = void;\n const boolConst :Bool = true;\n const int8Const :Int8 = -123;\n const int16Const :Int16 = -12345;\n const int32Const :Int32 = -12345678;\n const int64Const :Int64 = -123456789012345;\n const uint8Const :UInt8 = 234;\n const uint16Const :UInt16 = 45678;\n const uint32Const :UInt32 = 3456789012;\n const uint64Const :UInt64 = 12345678901234567890;\n const float32Const :Float32 = 1234.5;\n const float64Const :Float64 = -123e45;\n const textConst :Text = \"foo\";\n const dataConst :Data = \"bar\";\n const structConst :TestAllTypes = (\n voidField = void,\n boolField = true,\n int8Field = -12,\n int16Field = 3456,\n int32Field = -78901234,\n int64Field = 56789012345678,\n uInt8Field = 90,\n uInt16Field = 1234,\n uInt32Field = 56789012,\n uInt64Field = 345678901234567890,\n float32Field = -1.25e-10,\n float64Field = 345,\n textField = \"baz\",\n dataField = \"qux\",\n structField = (\n textField = \"nested\",\n structField = (textField = \"really nested\")),\n enumField = baz,\n # interfaceField can't have a default\n\n voidList = [void, void, void],\n boolList = [false, true, false, true, true],\n int8List = [12, -34, -0x80, 0x7f],\n int16List = [1234, -5678, -0x8000, 0x7fff],\n int32List = [12345678, -90123456, -0x80000000, 0x7fffffff],\n int64List = [123456789012345, -678901234567890, -0x8000000000000000, 0x7fffffffffffffff],\n uInt8List = [12, 34, 0, 0xff],\n uInt16List = [1234, 5678, 0, 0xffff],\n uInt32List = [12345678, 90123456, 0, 0xffffffff],\n uInt64List = [123456789012345, 678901234567890, 0, 0xffffffffffffffff],\n float32List = [0, 1234567, 1e37, -1e37, 1e-37, -1e-37],\n float64List = [0, 123456789012345, 1e306, -1e306, 1e-306, -1e-306],\n textList = [\"quux\", \"corge\", \"grault\"],\n dataList = [\"garply\", \"waldo\", \"fred\"],\n structList = [\n (textField = \"x \" \"structlist\"\n \" 1\"),\n (textField = \"x structlist 2\"),\n (textField = \"x structlist 3\")],\n enumList = [qux, bar, grault]\n # interfaceList can't have a default\n );\n const enumConst :TestEnum = corge;\n\n const voidListConst :List(Void) = [void, void, void, void, void, void];\n const boolListConst :List(Bool) = [true, false, false, true];\n const int8ListConst :List(Int8) = [111, -111];\n const int16ListConst :List(Int16) = [11111, -11111];\n const int32ListConst :List(Int32) = [111111111, -111111111];\n const int64ListConst :List(Int64) = [1111111111111111111, -1111111111111111111];\n const uint8ListConst :List(UInt8) = [111, 222] ;\n const uint16ListConst :List(UInt16) = [33333, 44444];\n const uint32ListConst :List(UInt32) = [3333333333];\n const uint64ListConst :List(UInt64) = [11111111111111111111];\n const float32ListConst :List(Float32) = [5555.5, inf, -inf, nan];\n const float64ListConst :List(Float64) = [7777.75, inf, -inf, nan];\n const textListConst :List(Text) = [\"plugh\", \"xyzzy\", \"thud\"];\n const dataListConst :List(Data) = [\"oops\", \"exhausted\", \"rfc3092\"];\n const structListConst :List(TestAllTypes) = [\n (textField = \"structlist 1\"),\n (textField = \"structlist 2\"),\n (textField = \"structlist 3\")];\n const enumListConst :List(TestEnum) = [foo, garply];\n}\n\nconst globalInt :UInt32 = 12345;\nconst globalText :Text = \"foobar\";\nconst globalStruct :TestAllTypes = (int32Field = 54321);\nconst globalPrintableStruct :TestPrintInlineStructs = (someText = \"foo\");\nconst derivedConstant :TestAllTypes = (\n uInt32Field = .globalInt,\n textField = TestConstants.textConst,\n structField = TestConstants.structConst,\n int16List = TestConstants.int16ListConst,\n structList = TestConstants.structListConst);\n\nconst genericConstant :TestGenerics(TestAllTypes, Text) =\n (foo = (int16Field = 123), rev = (foo = \"text\", rev = (foo = (int16Field = 321))));\n\nconst embeddedData :Data = embed \"testdata/packed\";\nconst embeddedText :Text = embed \"testdata/short.txt\";\nconst embeddedStruct :TestAllTypes = embed \"testdata/binary\";\n\nconst nonAsciiText :Text = \"♫ é ✓\";\n\nstruct TestAnyPointerConstants {\n anyKindAsStruct @0 :AnyPointer;\n anyStructAsStruct @1 :AnyStruct;\n anyKindAsList @2 :AnyPointer;\n anyListAsList @3 :AnyList;\n\n}\n\nconst anyPointerConstants :TestAnyPointerConstants = (\n anyKindAsStruct = TestConstants.structConst,\n anyStructAsStruct = TestConstants.structConst,\n anyKindAsList = TestConstants.int32ListConst,\n anyListAsList = TestConstants.int32ListConst,\n);\n\ninterface TestInterface {\n foo @0 (i :UInt32, j :Bool) -> (x :Text);\n bar @1 () -> ();\n baz @2 (s: TestAllTypes);\n}\n\ninterface TestExtends extends(TestInterface) {\n qux @0 ();\n corge @1 TestAllTypes -> ();\n grault @2 () -> TestAllTypes;\n}\n\ninterface TestExtends2 extends(TestExtends) {}\n\ninterface TestPipeline {\n getCap @0 (n: UInt32, inCap :TestInterface) -> (s: Text, outBox :Box);\n testPointers @1 (cap :TestInterface, obj :AnyPointer, list :List(TestInterface)) -> ();\n getAnyCap @2 (n: UInt32, inCap :Capability) -> (s: Text, outBox :AnyBox);\n\n struct Box {\n cap @0 :TestInterface;\n }\n struct AnyBox {\n cap @0 :Capability;\n }\n}\n\ninterface TestCallOrder {\n getCallSequence @0 (expected: UInt32) -> (n: UInt32);\n # First call returns 0, next returns 1, ...\n #\n # The input `expected` is ignored but useful for disambiguating debug logs.\n}\n\ninterface TestTailCallee {\n struct TailResult {\n i @0 :UInt32;\n t @1 :Text;\n c @2 :TestCallOrder;\n }\n\n foo @0 (i :Int32, t :Text) -> TailResult;\n}\n\ninterface TestTailCaller {\n foo @0 (i :Int32, callee :TestTailCallee) -> TestTailCallee.TailResult;\n}\n\ninterface TestStreaming {\n doStreamI @0 (i :UInt32) -> stream;\n doStreamJ @1 (j :UInt32) -> stream;\n finishStream @2 () -> (totalI :UInt32, totalJ :UInt32);\n # Test streaming. finishStream() returns the totals of the values streamed to the other calls.\n}\n\ninterface TestHandle {}\n\ninterface TestMoreStuff extends(TestCallOrder) {\n # Catch-all type that contains lots of testing methods.\n\n callFoo @0 (cap :TestInterface) -> (s: Text);\n # Call `cap.foo()`, check the result, and return \"bar\".\n\n callFooWhenResolved @1 (cap :TestInterface) -> (s: Text);\n # Like callFoo but waits for `cap` to resolve first.\n\n neverReturn @2 (cap :TestInterface) -> (capCopy :TestInterface);\n # Doesn't return. You should cancel it.\n\n hold @3 (cap :TestInterface) -> ();\n # Returns immediately but holds on to the capability.\n\n callHeld @4 () -> (s: Text);\n # Calls the capability previously held using `hold` (and keeps holding it).\n\n getHeld @5 () -> (cap :TestInterface);\n # Returns the capability previously held using `hold` (and keeps holding it).\n\n echo @6 (cap :TestCallOrder) -> (cap :TestCallOrder);\n # Just returns the input cap.\n\n expectCancel @7 (cap :TestInterface) -> ();\n # evalLater()-loops forever, holding `cap`. Must be canceled.\n\n methodWithDefaults @8 (a :Text, b :UInt32 = 123, c :Text = \"foo\") -> (d :Text, e :Text = \"bar\");\n\n methodWithNullDefault @12 (a :Text, b :TestInterface = null);\n\n getHandle @9 () -> (handle :TestHandle);\n # Get a new handle. Tests have an out-of-band way to check the current number of live handles, so\n # this can be used to test garbage collection.\n\n getNull @10 () -> (nullCap :TestMoreStuff);\n # Always returns a null capability.\n\n getEnormousString @11 () -> (str :Text);\n # Attempts to return an 100MB string. Should always fail.\n\n writeToFd @13 (fdCap1 :TestInterface, fdCap2 :TestInterface)\n -> (fdCap3 :TestInterface, secondFdPresent :Bool);\n # Expects fdCap1 and fdCap2 wrap socket file descriptors. Writes \"foo\" to the first and \"bar\" to\n # the second. Also creates a socketpair, writes \"baz\" to one end, and returns the other end.\n}\n\ninterface TestMembrane {\n makeThing @0 () -> (thing :Thing);\n callPassThrough @1 (thing :Thing, tailCall :Bool) -> Result;\n callIntercept @2 (thing :Thing, tailCall :Bool) -> Result;\n loopback @3 (thing :Thing) -> (thing :Thing);\n\n waitForever @4 ();\n\n interface Thing {\n passThrough @0 () -> Result;\n intercept @1 () -> Result;\n }\n\n struct Result {\n text @0 :Text;\n }\n}\n\nstruct TestContainMembrane {\n cap @0 :TestMembrane.Thing;\n list @1 :List(TestMembrane.Thing);\n}\n\nstruct TestTransferCap {\n list @0 :List(Element);\n struct Element {\n text @0 :Text;\n cap @1 :TestInterface;\n }\n}\n\ninterface TestKeywordMethods {\n delete @0 ();\n class @1 ();\n void @2 ();\n return @3 ();\n}\n\ninterface TestAuthenticatedBootstrap(VatId) {\n getCallerId @0 () -> (caller :VatId);\n}\n\nstruct TestSturdyRef {\n hostId @0 :TestSturdyRefHostId;\n objectId @1 :AnyPointer;\n}\n\nstruct TestSturdyRefHostId {\n host @0 :Text;\n}\n\nstruct TestSturdyRefObjectId {\n tag @0 :Tag;\n enum Tag {\n testInterface @0;\n testExtends @1;\n testPipeline @2;\n testTailCallee @3;\n testTailCaller @4;\n testMoreStuff @5;\n }\n}\n\nstruct TestProvisionId {}\nstruct TestRecipientId {}\nstruct TestThirdPartyCapId {}\nstruct TestJoinResult {}\n\nstruct TestNameAnnotation $Cxx.name(\"RenamedStruct\") {\n union {\n badFieldName @0 :Bool $Cxx.name(\"goodFieldName\");\n bar @1 :Int8;\n }\n\n enum BadlyNamedEnum $Cxx.name(\"RenamedEnum\") {\n foo @0;\n bar @1;\n baz @2 $Cxx.name(\"qux\");\n }\n\n anotherBadFieldName @2 :BadlyNamedEnum $Cxx.name(\"anotherGoodFieldName\");\n\n struct NestedStruct $Cxx.name(\"RenamedNestedStruct\") {\n badNestedFieldName @0 :Bool $Cxx.name(\"goodNestedFieldName\");\n anotherBadNestedFieldName @1 :NestedStruct $Cxx.name(\"anotherGoodNestedFieldName\");\n\n enum DeeplyNestedEnum $Cxx.name(\"RenamedDeeplyNestedEnum\") {\n quux @0;\n corge @1;\n grault @2 $Cxx.name(\"garply\");\n }\n }\n\n badlyNamedUnion :union $Cxx.name(\"renamedUnion\") {\n badlyNamedGroup :group $Cxx.name(\"renamedGroup\") {\n foo @3 :Void;\n bar @4 :Void;\n }\n baz @5 :NestedStruct $Cxx.name(\"qux\");\n }\n}\n\ninterface TestNameAnnotationInterface $Cxx.name(\"RenamedInterface\") {\n badlyNamedMethod @0 (badlyNamedParam :UInt8 $Cxx.name(\"renamedParam\")) $Cxx.name(\"renamedMethod\");\n}\n"),
}