From a3f7a4e7585c4d000443918ec6bd1fad13180dbc Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Thu, 11 Apr 2019 08:43:30 -0500 Subject: [PATCH] Remove accidentally-merged binary.bs/spec.bs --- proposals/host-bindings/binary.bs | 840 ------------------------------ proposals/host-bindings/spec.bs | 118 ----- 2 files changed, 958 deletions(-) delete mode 100644 proposals/host-bindings/binary.bs delete mode 100644 proposals/host-bindings/spec.bs diff --git a/proposals/host-bindings/binary.bs b/proposals/host-bindings/binary.bs deleted file mode 100644 index 95d0537f32..0000000000 --- a/proposals/host-bindings/binary.bs +++ /dev/null @@ -1,840 +0,0 @@ -
-Title: Binary Representation of WebIDL
-Shortname: binaryWebIDL
-Level: 1
-Status: ED
-Group: wasm
-TR: http://www.w3.org/TR/wasm-webidl-1
-URL: http://webassembly.github.io/spec/webidl
-Editor: Francis McCabe, Google Inc., fgm@google.com
-Abstract: A binary encoding of webIDL suitable for processing by WASM engines.
-Markup Shorthands: markdown yes
-
- -
-{
-  "WEBASSEMBLY": {
-    "href": "https://webassembly.github.io/spec/core/",
-    "title": "WebAssembly Core Specification",
-    "publisher": "W3C WebAssembly Community Group",
-    "status": "Draft"
-  },
-  "webIDL" : {
-    "href" : "http://heycam.github.io/webidl",
-    "title" : "Web IDL",
-    "publisher" : "W3C",
-    "status" : "Editor's Draft"
-  }
-}
-
- -Introduction {#intro} -===================== - -In order to be able to process webIDL signatures efficiently it is -convenient to support a binary representation of the webIDL. - -This specification mirrors the official specification [[!webIDL]] in most -ways. However, the binary encoding may admit non-legal forms of -webIDL. Furthermore, some of the artifacts of webIDL do not apply to any binary -encoding. - -A webIDL specification consists of a sequence of top-level elements. Each of -these top-level elements may define a type; an interface; or a name space. - -Notation {#notation} --------- - -A production that defines a part of this encoding is written in the form: - -``` -NT(Arg) => Body -``` -where *Body* is a sequence of terminals and non-terminals. - -The terminals are either single characters (ASCII) or byte codes -- represented -as hex sequences. - -A Non Terminal is represented as a name enclosed in angle brackets followed -optionally by an argument in parentheses and/or a repeat count -- a number or -argument enclosed in braces. - -Multiple productions may be applicable to a given non-terminal; these are -represented as multiple rules. - -Non terminals may have argument expressions, the constraint on the production is -that all occurrences of a given argument variable must have the same value. - -
-For example, in the production: - -``` -NullableType => 0x72 0x08 N u l l a b l e 0x01 Type -``` -the term `Type` refers to the non terminal `Type`. -
- -
-Similary, the production: -``` -String => u32(C) CodePoint{C} -``` - -denotes the fact that a `String` is represented by a count `C` -- which -satisfies the `u32` non-terminal -- followed by `C` CodePoints. -
- - -Binary AST {#ast} -========== - -The binary encoding is layered on a basic set of primitives that -permit the encoding of integers, strings and combinations of entities. - -Encoding Integers {#integer-encoding} ------------------ - -Integers are encoded using the LEB128 variable length integer encoding. Although -the LEB format is able to represent both signed and unsigned integers, this -specification only uses unsigned integers. - -``` -7bit(0) => 0x00 -7bit(1) => 0x01 -... -7bit(127) => 0x7f - -8bit(0) => 0x80 -8bit(1) => 0x81 -... -8bit(127) => 0xff - -u32(Ix) => 7bit(Ix) -u32(Ix<<7+Lx) => 8bit(Lx) u32(Ix) -``` - -Encoding Vectors {#vector-encoding} ----------------- - -A vector of entities is encoded as a length integer (itself encoded as LEB128) -following length entries of the vector -- each of which is of the expected type. - -Encoding Strings {#string-encoding} ----------------- - -A string is encoded as a vector of Codepoints represented as sequences of UTF8 -bytes. - -``` -String => u32(L) CodePoint{L} -``` - -Standard Scheme {#standard-scheme} ---------------- - -All of the encodings follow a common scheme, consisting of a single lead-in byte -followed by type specific content. Any collections are preceded by a length -(encoded as an LEB) so that a streaming parser knows exactly how much input to -consume. - -For convenience, in the presentation, where a literal string is required in the -encoding it is listed using the string's characters spaced out. - -
-For example, the encoding: - -``` -0x71 0x09 D O M S t r i n g -``` -is a convenience form of the sequence of bytes: - -``` -0x71 0x09 0x44 0x4f 0x4d 0x53 0x74 0x72 0x69 0x6e 0x67 -``` -
- -Note: all of the type names defined in this document use only ASCII characters -in their name. - -Many of the primitive types are encoded as single bytes; and where applicable, -use the same encoding as for their WASM counterparts. - -Top-level Elements {#top-level} -================= - -A complete encoding of a webIDL consists of a sequence of top-level -elements. These top-level elements can be viewed as defining a set of interfaces -and/or types. - -Note that a given use of the binary encoding may not *start* at the -top-level. It may be that a `Type` or an `Interface` is encoded. This is -application specific. - -``` -WebIDL => u32(C) TopLevel{C} - -TopLevel => TypeDef -TopLevel => InterfaceDef -TopLevel => DictionaryDef -TopLevel => EnumerationDef -TopLevel => NamespaceDef -``` - -TypeDef {#type-def} ------- - -A `TypeDef` is a way of giving a name to a type: - -``` -TypeDef => 0x01 String Type -``` - -InterfaceDef {#interface-def} --------- - -An `InterfaceDef` gives a name to an interface. - -``` -InterfaceType => 0x02 String Type u32(C) InterfaceMember{C} -``` - -DictionaryDef {#dictionary-def} -------------- - -``` -DictionaryDef => 0x03 String Type u32(F) DictionaryMember{F} - -DictionaryMember => WriteableDictionaryMember -DictionaryMember => ReadOnlyDictionaryMember -DictionaryMember => 0x6a String DictionaryMember - -WriteableDictionaryMember => 0x01 String Type -ReadOnlyDictionaryMember => 0x02 String Type -``` - -Note: This specification does not support partially specified dictionaries. - -EnumerationDef {#enumeration-def} ----------------- - -An `EnumerationDef` defines a type by enumerating its values as one of a set of -strings. - -``` -EnumerationDef => 0x04 String u32(C) String{C} -``` - -NamespaceDef {#namespace-def} ------------ - -A `NameSpace` simultaneously defines an `Interface` and a singleton that -implements that interface. - -``` -NameSpaceDef => 0x05 String u32(C) NameSpaceMember{C} -``` - -The `NameSpaceMember`s are a subset of the `InterfaceMember`s that refer to -regular operations and attributes. - -``` -NameSpaceMember => 0x02 String Type -NameSpaceMember => 0x6a String NameSpaceMember -``` - -Note: all elemements of a `NameSpace` are read-only in nature. - -Type {#type} -===== - -``` -Type => VoidType -Type => AnyType -Type => NumericType -Type => StringType -Type => ObjectType -Type => ErrorType -Type => NamedType -Type => GenericType -Type => BufferSourceType -Type => CompoundType -``` - -Void {#void-type} ----- - -``` -VoidType => 0x40 -``` - -Any { #any-type} ---- - -``` -AnyType => 0x6f -``` - -Numeric Types {#numeric-types} -============= - -The numeric types correspond to numeric values. - -``` -NumericType => Boolean -NumericType => Octet -NumericType => Short -NumericType => UnsignedShort -NumericType => Long -NumericType => UnsignedLong -NumericType => LongLong -NumericType => UnsignedLongLong -NumericType => Float -NumericType => UnrestrictedFloat -NumericType => Double -NumericType => UnrestrictedDouble -``` - -Boolean { #boolean-type} -------- - -``` -BooleanType => 0x79 -``` - -Octet {#octet-type} ------ - -``` -OctetType => 0x7a -``` - -(Otherwise known as an unsigned byte) - -Short { #short-type} ------ - -``` -ShortType => 0x7b -``` - -Unsigned Short { #unsigned-short-type} --------------- - -``` -UnsignedShortType => 0x78 -``` - -Long {#long-type} ----- - -``` -LongType => 0x7f -``` - -Unsigned Long {#unsigned-long-type} -------------- - -``` -UnsignedLongType => 0x77 -``` - -Long Long {#long-long-type} ---------- - -``` -LongLongType => 0x7e -``` - -Unsigned Long Long {#unsigned-long-long-type} ------------------- - -``` -UnsignedLongLongType => 0x76 -``` - -Float {#float-type} ------ - -``` -FloatType => 0x75 -``` - -Unrestricted Float {#unrestricted-float-type} ------------------- - -``` -UnrestrictedFloatType => 0x7d -``` - -Double {#double-type} ------- - -``` -DoubleType => 0x74 -``` - -Unrestricted Double {#unrestricted-double-type} -------------------- - -``` -UnrestrictedDoubleType => 0x7c -``` - -String Style Types {#string-style-types} -================= - -``` -StringType => DOMStringType -StringType => ByteStringType -StringType => USVStringType -StringType => SymbolType -``` - -DOMString {#dom-string-type} ---------- - -``` -DOMStringType => 0x71 0x09 D O M S t r i n g -``` - -ByteString {#byte-string-type} ----------- - -``` -ByteStringType => 0x71 0x0a B y t e S t r i n g -``` - -USVString {#usv-string-type} ---------- - -``` -USVStringType => 0x71 0x09 U S V S t r i n g -``` - -Object {#object-type} ------- - -``` -ObjectType => 0x71 0x06 O b j e c t -``` - -Symbol {#symbol-type} ------- - -``` -SymbolType => 0x71 0x06 S y m b o l -``` - -Error {#error-type} ------ - -``` -ErrorType => 0x71 0x05 E r r o r -``` -Named Type {#named-type} ----------- - -``` -NamedType => 0x71 u32(L) CodePoint{L} -``` - -A `NamedType` refers to a type that is defined by one of the standard webIDL -elements: `InterfaceDef`, `EnumerationDef`, or `DictionaryDef`. - -Note that some of the standard types are also encoded as named types. - -Type Combinations {#type-combinations} -================= - -Type combinations include various forms of generic type and -functions. - -Generic Type {#generic-type} ------------- - -Note that the concept of a generic type is not a standard part of web IDL; -although webIDL has many generic types in its specification. The definition of -`GenericType` is included here as a form of documentation. - -``` -GenericType => 0x72 u32(L) CodePoint{L} u32(A) Type{A} - -GenericType => NullableType -GenericType => SequenceType -GenericType => PromiseType -GenericType => RecordType -GenericType => FunctionType -GenericType => FrozenArrayType -``` - -Some of the standard types are generic, for example, the `Promise` type is -generic in one type argument; although, often, there are additional restrictions -on the possible instantiations of the generic type that are not reflected in -this specification. - -A type expression intended to denote `Promise(long)` would be encoded: - -``` -PromiseType => 0x72 0x06 P r o m i s e 0x01 0x7f -``` - -Nullable Type {#nullable-type} -------------- - -``` -NullableType => 0x72 0x08 N u l l a b l e 0x01 Type -``` - -Sequence Type {#sequence-type} -------------- - -``` -SequenceType => 0x72 0x08 S e q u e n c e 0x01 Type -``` - -Promise Type {#promise-type} ------------- - -``` -PromiseType => 0x72 0x06 P r o m i s e 0x01 Type -``` -Record Type {#record-type} ------------ - -``` -RecordType => 0x72 0x06 R e c o r d 0x02 Type Type -``` -The first type in the vector of type arguments is the type of keys in the record -and the second is the type of values in the record. - -Function Type {#function-type} -------------- - -``` -FunctionType => 0x60 u32(A) Type{A} u32(R) Type{R} -``` -Note that the `optional` argument in webIDL is not directly modeled in the -binary representation. Instead, use multiple instances of a function type -declaration. - -FrozenArray Type {#frozen-array-type} ------------------ - -``` -FrozenArrayType => 0x72 0x0b F r o z e n A r r a y 0x01 Type -``` - -Buffer Source Types {#buffer-source-types} -=================== - -``` -BufferSourceType => ArrayBuffer -BufferSourceType => DataView -BufferSourceType => Int8Array -BufferSourceType => Int16Array -BufferSourceType => Int32Array -BufferSourceType => UInt8Array -BufferSourceType => UInt16Array -BufferSourceType => UInt32Array -BufferSourceType => UInt8ClampedArray -BufferSourceType => Float32Array -BufferSourceType => Float64Array -``` - -ArrayBuffer Type {#arraybuffer-type} ------------------ - -``` -ArrayBufferType => 0x71 0x0b A r r a y B u f f e r -``` - -DataView Type {#dataview-type} ------------------ - -``` -DataViewType => 0x71 0x08 D a t a V i e w -``` - -Int8Array Type {#int8array-type} --------------- - -``` -Int8ArrayType => 0x71 0x09 I n t 8 A r r a y -``` - -Int16Array Type {#int16array-type} --------------- - -``` -Int16ArrayType => 0x71 0x0a I n t 1 6 A r r a y -``` - -Int32Array Type {#int32array-type} --------------- - -``` -Int32ArrayType => 0x71 0x0b I n t 3 2 A r r a y -``` - -Uint8Array Type {#uint8array-type} --------------- - -``` -Uint8ArrayType => 0x71 0x0a U i n t 8 A r r a y -``` - -Uint16Array Type {#uint16array-type} --------------- - -``` -Uint16ArrayType => 0x71 0x0b U i n t 1 6 A r r a y -``` - -Uint32Array Type {#uint32array-type} --------------- - -``` -Uint32ArrayType => 0x71 0x0c U i n t 3 2 A r r a y -``` - -Float32Array Type {#float32array-type} --------------- - -``` -Float32ArrayType => 0x71 0x0c F l o a t 3 2 A r r a y -``` - -Float64Array Type {#float64array-type} --------------- - -``` -Float64ArrayType => 0x71 0x0c F l o a t 6 4 A r r a y -``` - - -Compound Types {#compound-types} -============== - -``` -CompoundType => UnionType -CompoundType => AnnotatedType -``` - - -Union Type {#union-type} ----------- - -``` -UnionType => 0x6c u32(C) Type{C} -``` - -Annotated Types {#annotated-types} --------------- - -``` -AnnotatedType => 0x6a String Type -``` - -In this encoding, annotations are not parsed out. A future extension/revision -may change this. - -Extended Attributes {#extended-attributes} ------------------- - -In addition to individual types being annotatable (sic) elements of dictionaries -and interfaces may also be annotated. In this specification we do not specify a -specific encoding for such extended attributes; we merely represent the -entireannotation as a string. However, webIDL puts other constraints on the -legitimate forms of such attributes. - -Interface Definition {#interface-type} -==================== - -``` -InterfaceDef => 0x02 String Type u32(C) InterfaceMember{C} - -InterfaceMember => ConstantMember -InterfaceMember => RegularMember -InterfaceMember => StaticMember -InterfaceMember => OperationMember -InterfaceMember => SpecialOperationMember -InterfaceMember => IterableMember -InterfaceMember => MaplikeMember -InterfaceMember => SetlikeMember -InterfaceMember => AnnotatedInterfaceMember - -AnnotatedInterfaceMember => 0x6a String InterfaceMember -``` - -Constant Member {#constant-member} --------------- - -Constant members are not supported in the MAP. - -``` -ConstantMember => 0x01 String Type Value -``` - -Regular Member {#regular-member} -------------- - -A regular member has two variants: readonly and re-assignable: - -``` -RegularMember => ReadWriteMarker String Type - -ReadWriteMarker => 0x02 -ReadWriteMarker => 0x03 -``` - -The value 0x02 signifies a readonly attribute, 0x03 signifies a reassignable -attribute of the interface. - -Static Member {#static-member} ------------- - -``` -StaticMember => 0x04 String Type -``` - -Operation Member {#operation-member} ---------------- - -An operation member *looks like* a regular read-only member whose type is a -function type: - -``` -OperationMember => 0x02 String FunctionType -OperationMember => 0x04 String FunctionType -``` - -Special Operation Member {#special-operation-member} ---------------- - -A special operation member is a regular operation member with a distinguished -name, or is a property member: - -``` -SpecialOperationMember => 0x02 SpecialName FunctionType -SpecialOperationMember => 0x04 SpecialName FunctionType -SpecialOperationMember => PropertyMember - -PropertyMember => 0x05 SpecialName String Type - -SpecialName => 0x06 g e t t e r -SpecialName => 0x06 s e t t e r -SpecialName => 0x07 d e l e t e r -SpecialName => 0x0b s t r i n g i f i e r -``` - -IterableMember {#iterable-member} -------------- - -``` -IterableMember => 0x05 0x01 Type -IterableMember => 0x05 0x02 Type Type -``` - -Only styles of `IterableMember` are permitted, single-typed and double-typed. -In the former case, the iterator is a *value iterator* and in the case of two -types, it is a *pair iterator*: the first type is the key type and the second is -the value type. - -Annotated Member {#annotated-member} -------------- - - -``` -AnnotatedMember => 0x6a String InterfaceMember -``` - - -Examples {#worked-examples} -======== - -Note: Non-normative - -In this section we give some examples of webIDL that are encoded in this binary -encoding. - -Note: spaces below are not semantically significant; used for -presentation purposes only. - -Simple Interface Examples {#simple-interface-examples} -------------------------- - -
-[Exposed=Window]
-interface Paint { };
-
- -This empty interface is encoded: - -``` -0x6a 0x0e E x p o s e d = W i n d o w - 0x02 0x05 P a i n t 0x40 0x00 -``` - - -The `SolidCOlor` interface inherits from the `Paint` interface: - -
-[Exposed=Window]
-interface SolidColor : Paint {
-  attribute double red;
-  attribute double green;
-  attribute double blue;
-};
-
- -The elements of this interface are `double` values: - -``` -0x6a 0x0e E x p o s e d = W i n d o w - 0x02 0x0a S o l i d C o l o r 0x71 0x05 P a i n t 0x03 - 0x02 0x03 r e d 0x74 - 0x02 0x05 g r e e n 0x74 - 0x04 0x04 b l u e 0x74 -``` - -
-[Exposed=Window]
-interface Pattern : Paint {
-  attribute DOMString imageURL;
-};
-
- -``` -0x6a 0x0e E x p o s e d = W i n d o w - 0x02 0x07 P a t t e r n 0x71 0x05 P a i n t 0x01 - 0x02 0x08 i m a g e U R L 0x71 0x09 D O M S t r i n g -``` - - -
-[Exposed=Window, Constructor]
-interface GraphicalWindow {
-  readonly attribute unsigned long width;
-  readonly attribute unsigned long height;
-
-  attribute Paint currentPaint;
-
-  void drawRectangle(double x, double y, double width, double height);
-  void drawText(double x, double y, DOMString text);
-};
-
- -``` -0x6a 0x0e E x p o s e d = W i n d o w - 0x02 0x0f G r a p h i c a l W i n d o w 0x40 0x05 - 0x02 0x05 w i d t h 0x74 - 0x02 0x06 h e i g h t 0x74 - - 0x02 0x0c c u r r e n t P a i n t 0x71 0x05 P a i n t - - 0x02 0x0d d r a w R e c t a n g l e - 0x60 0x04 0x74 0x74 0x74 0x74 0x00 - 0x02 0x08 d r a w T e x t - 0x60 0x03 0x74 0x74 0x71 0x09 D O M S t r i n g -``` - diff --git a/proposals/host-bindings/spec.bs b/proposals/host-bindings/spec.bs deleted file mode 100644 index c637bb527b..0000000000 --- a/proposals/host-bindings/spec.bs +++ /dev/null @@ -1,118 +0,0 @@ -
-Title: WebAssembly webIDL Bindings
-Shortname: wasmWebIDLBinding
-Level: 1
-Status: ED
-Group: wasm
-TR: http://www.w3.org/TR/wasm-webidl-binding-1
-URL: http://webassembly.github.io/spec/webidl-binding
-Editor: Luke Wagner, Mozilla Inc., luke@mozilla.com
-Editor: Francis McCabe, Google Inc., fgm@google.com
-Abstract: Custom WebAssembly section for representing webIDL bindings for imported functions.
-Markup Shorthands: markdown yes
-
- -
-{
-  "WEBASSEMBLY": {
-    "href": "https://webassembly.github.io/spec/core/",
-    "title": "WebAssembly Core Specification",
-    "publisher": "W3C WebAssembly Community Group",
-    "status": "Draft"
-  },
-  "webIDL" : {
-    "href" : "http://heycam.github.io/webidl",
-    "title" : "Web IDL",
-    "publisher" : "W3C",
-    "status" : "Editor's Draft"
-  }
-  "webIDLBinary" : {
-    "href" : "http://heycam.github.io/wasm-webidl-1",
-    "title" : "Binary Representation of Web IDL",
-    "publisher" : "W3C",
-    "status" : "Editor's Draft"
-  }
-}
-
- -Introduction {#intro} -===================== - -This specification describes the format and semantics of a WebAssembly embedder -specification [=WEBASSEMBLY/custom section=] called "webIDL-binding". - -This specification allows an embedder to efficiently map imports exposed by the -WebAssembly module to functions whose implementations are known by the host. - -This specification is limited to those functions that have a webIDL -specification. Other host environments may require different means of -description and may require their own custom section. - -This specification is presented in two parts: a description of the features of -the specification in terms of a surface syntax. This surface syntax may be -present in source representations of WebAssembly modules. - -The second part of the specification describes the binary encoding of contents -of the `webIDL-binding` custom section. - - -WebIDL Binding Custom Section {#custom-section} -============================ - -Binding Map {#binding-map} ------------ - -WebIDL Types {#webIDL-types} ------------- - -Binding Operators {#binding-expressions} -================== - -As Cast -------- - -Utf8 String ----------- - -Utf8 CString ------------ - -I32-to-Enum ------------ - -Typed View ---------- - -Typed Copy ---------- - -Dictionary ----------- - -Bind ----- - -Get Cast -------- - -Alloc Utf8 String ----------------- - -Alloc Copy ----------- - -Enum to I32 ------------ - -Dictionary Field ---------------- - -Bind Import ------------ - -Conformance Requirements {#conformance} -======================== - -Binary Encoding {#binary} -============== -