FIDL compiler error catalog

This document lists all errors emitted by the FIDL compiler, fidlc. Error identifiers in this domain are always rendered with the prefix fi- followed by a four digit code, like fi-0123.

fi-0001: Invalid character

The lexer failed to convert a character into a token at the specified location.

library test.bad.fi0001;

type ßar = struct {
    value uint64;
};

An invalid character should be fixed by substitution or removal.

library test.good.fi0001;

type Foo = struct {
    value uint64;
};

Invalid characters are location dependent. Please refer to the FIDL language specification to determine which characters are permitted in each part of the FIDL syntax.

fi-0002: Unexpected line break

String literals are not allowed to be split across multiple lines:

library test.bad.fi0002;

const BAD_STRING string:1 = "Hello
World";

Instead, use the escape sequence \n to represent a line break:

library test.good.fi0002;

const GOOD_STRING string:11 = "Hello\nWorld";

fi-0003: Invalid escape sequence

The lexer encountered an invalid character at the beginning of an escape sequence.

library test.bad.fi0003;

const UNESCAPED_BACKSLASH string:2 = "\ ";
const BACKSLASH_TYPO string:1 = "\i";
const CODE_POINT_TYPO string:1 = "\Y1F604";

Substitute a valid character to begin the escape sequence, or remove the unintended backslash character.

library test.good.fi0003;

const ESCAPED_BACKSLASH string:2 = "\\ ";
const REMOVED_BACKSLASH string:1 = "i";
const SMALL_CODE_POINT string:3 = "\u{2604}";
const BIG_CODE_POINT string:4 = "\u{01F604}";

Refer to the FIDL grammar specification for valid escape sequences.

fi-0004: Invalid hex digit

Unicode escapes in string literals must not contain invalid hex digits:

library test.bad.fi0004;

const SMILE string = "\u{1G600}";

You must specify a valid Unicode code point in hexadecimal, from 0 to 10FFFF. Each hex digit must be a number from 0 to 9, a lowercase letter from a to f, or an uppercase letter from A to F. In this case, G was a typo for F:

library test.good.fi0004;

const SMILE string = "\u{1F600}";

fi-0005

fi-0006: Expected declaration

This error happens when FIDL expects a declaration and finds something else. This is often caused by a typo. The valid declarations are: type, alias, const, using, protocol, and service.

library test.bad.fi0006;

cosnt SPELLED_CONST_WRONG string:2 = ":("; // Expected a declaraction (such as const).

To fix this error, check for typos in your top-level declarations and ensure you're only using features that are supported by FIDL.

library test.good.fi0006;

const SPELLED_CONST_RIGHT string:2 = ":)";

fi-0007: Unexpected token

This error occurs when an unexpected token is encountered during parsing. Generally speaking, this is the result of a typo:

library test.bad.fi0007;

alias MyType = vector<uint8>:<,256,optional>; // Extra leading comma

The fix to this problem is typically to remove the unexpected token, or in some cases, provide the rest of the missing syntax:

library test.good.fi0007;

alias MyType = vector<uint8>:<256, optional>;

fi-0008: Unexpected token

This error happens whenever the FIDL parser encounters a grammatically invalid token. This can happen many ways--for example a missing = for an enum member, an extra token such as library = what.is.that.equals.doing.there, and so on.

library test.bad.unexpectedtokenofkind;

type Numbers = flexible enum {
    ONE; // FIDL enums don't have a default value.
};

Generally, the fix to this problem will be adding a missing token or removing an extra one.

library test.good.fi0008;

type Numbers = flexible enum {
    ONE = 1;
};

To avoid this error, do a once over on your *.fidl files to make sure they're grammatically correct.

fi-0009: Unexpected identifier

This error usually occurs when an identifier is used in an incorrect position:

using test.bad.fi0009;

Use the correct identifier instead:

library test.good.fi0009;

fi-0010: Invalid identifier

An identifier was found which does not meet the requirements for valid identifiers. FIDL identifiers may contain alphanumerics and underscores (specifically A-Z, a-z, 0-9, and _), and additionally each identifier must begin with a letter and end with either a letter or number.

library test.bad.fi0010a;

// Foo_ is not a valid identifier because it ends with '_'.
type Foo_ = struct {
    value uint64;
};

To fix this, change the identifier to make sure it contains only valid characters, starts with a letter, and ends with a letter or number.

library test.good.fi0010a;

type Foo = struct {
    value uint64;
};

This error may also occur if a multi-part (dotted) identifier is passed to an attribute.

library test.bad.fi0010b;

@foo(bar.baz="Bar", zork="Zoom")
type Empty = struct{};

To fix this, change to use only single-part identifiers in attributes.

library test.good.fi0010b;

@foo(bar="Bar", zork="Zoom")
type Empty = struct {};

fi-0011: Invalid library name component

Library names must only contain letters and numbers (A-Z, a-z, and 0-9), and must start with a letter.

library test.bad.fi0011.name_with_underscores;

To fix this, ensure that all library name components meet the requirements.

library test.good.fi0011.namewithoutunderscores;

fi-0012: Invalid type layout class

Type declarations must specify a layout known to FIDL:

library test.bad.fi00012;

type Foo = invalid {};

The valid layouts are bits, enum, struct, table, and union:

library test.good.fi0012;

type Empty = struct {};

A layout is a parameterizable description of a FIDL type. It refers to a family of would-be types which can receive further arguments to specify their shape. For example, a struct is a kind of layout which becomes a concrete type when it has specific members defined, while an array is a layout that becomes concrete when given a type to be repeated sequentially a specified number of times.

Layouts are all built into the FIDL language - there is no means by which users can specify their own layouts, or create their own generic type templates.

fi-0013: Invalid wrapped type

This error occurs when the value passed to an enum or bits declaration isn't an identifier for a type, such as when you instead provide a string value as the "backing type":

library test.bad.fi0013;

type TypeDecl = enum : "int32" {
    FOO = 1;
    BAR = 2;
};

To fix this error, make sure the backing type for the enum or bits is a type identifier.

library test.good.fi0013;

type TypeDecl = enum : int32 {
    FOO = 1;
    BAR = 2;
};

fi-0014: Attribute with empty parentheses

This error occurs if an attribute has parentheses but no arguments.

library test.bad.fi0014;

@discoverable()
protocol MyProtocol {};

To fix it, remove the parentheses from attributes with no arguments, or supply arguments if arguments were intended.

library test.good.fi0014;

@discoverable
protocol MyProtocol {};

FIDL disallows empty argument lists on attributes mostly as a stylistic choice.

fi-0015: Attribute args must all be named

For clarity, when an attribute has more than one argument, all of the attribute's arguments must be explicitly named.

This error occurs when an attribute has more than one argument but does not explicitly provide names for the arguments.

library test.bad.fi0015;

@foo("abc", "def")
type MyStruct = struct {};

To fix it, provides names for all of the arguments using name=value syntax.

library test.good.fi0015;

@foo(bar="abc", baz="def")
type MyStruct = struct {};

fi-0016: Missing ordinal before member

This error occurs when a fields in a union or table is missing an ordinal.

library test.bad.fi0016a;

type Foo = table {
    x int64;
};

library test.bad.fi0016b;

type Bar = union {
    foo int64;
    bar vector<uint32>:10;
};

To fix this error, explicitly specify the ordinals for the table or union:

library test.good.fi0016;

type Foo = table {
    1: x int64;
};

type Bar = union {
    1: foo int64;
    2: bar vector<uint32>:10;
};

Unlike structs, tables and unions are designed to allow backwards-compatible changes to be made to their contents. In order to enable this, a consistent value, the ordinal, is needed to identify table fields or union variants. To avoid confusion and make it harder to accidentally change ordinals when changing a table or union, ordinals must always be specified explicitly.

fi-0017: Ordinal out of bound

Ordinals for tables and Unions must be valid unsigned 32 bit integers. Negative ordinals or ordinals greater than 4,294,967,295 will cause this error.

library test.bad.fi0017a;

type Foo = table {
  -1: foo string;
};

library test.bad.fi0017b;

type Bar = union {
  -1: foo string;
};

To fix this error, ensure that all ordinals are in the allowed range.

library test.good.fi0017;

type Foo = table {
    1: foo string;
};

type Bar = union {
    1: foo string;
};

fi-0018: Ordinals must start at 1

Neither table nor union member ordinal values are allowed to be 0:

library test.bad.fi0018;

type Foo = strict union {
    0: foo uint32;
    1: bar uint64;
};

Instead, numbering should start from 1:

library test.good.fi0018;

type Foo = strict union {
    1: foo uint32;
    2: bar uint64;
};

fi-0019: Strict bits, enum, or union cannot be empty

A strict bits, enum, or union is not allowed to have zero members:

library test.bad.fi0019;

type Numbers = strict enum {};

Instead, there must be at least one member:

library test.good.fi0019a;

type Numbers = flexible enum {};

Alternatively, you can mark the declaration flexible instead of strict:

library test.good.fi0019b;

type Numbers = strict enum {
    ONE = 1;
};

An empty bits, enum, or union carries no information, so it should not normally be used in an API. However, flexible data types are designed for evolution, so it makes sense to define a flexible bits or enum that starts out empty, with the expectation of adding members later on. You should always think carefully about whether to use strict or flexible when defining a new data type.

fi-0020: Invalid protocol member

This error occurs when an item in a protocol is not recognized as a valid protocol member such as when something in a protocol is not a protocol composition, one-way method, two-way method, or event.

library test.bad.fi0020;

protocol Example {
    NotAMethodOrCompose;
};

To fix this error, remove the invalid items or convert them to the correct syntax for the type of protocol item they were intended to be.

library test.good.fi0020;

protocol Example {
    AMethod();
};

fi-0021

fi-0022: Cannot attach attribute to identifier

This error occurs when an attribute is placed on the type of a declaration when that type is an identifier type. For example, placing an attribute after field name but before the field's type in a struct declaration associates the attribute with the type of the field rather than with the field itself. If the type of the field is a preexisting type being referenced by name, additional attributes cannot be applied to it.

library test.bad.fi0022;

type Foo = struct {
    // uint32 is an existing type, extra attributes cannot be added to it just
    // for this field.
    data @foo uint32;
};

If the intent was to apply an attribute to the field, the attribute should be moved before the field name.

Attributes can be applied to types where they are declared. This means that if the type of a struct field or other similar declaration is an anonymous type rather than an identifier type, attributes can be applied to the type.

library test.good.fi0022;

type Foo = struct {
    // The foo attribute is associated with the data1 field, not the uint32
    // type.
    @foo
    data1 uint32;
    // The type of data2 is a newly declared anonymous structure, so that new
    // type can have an attribute applied to it.
    data2 @foo struct {};
};

fi-0023: Attribute inside type declaration

With inline layouts, you can put attributes directly before the layout. However, when declaring a type at the top level, you cannot:

library test.bad.fi0023;

type Foo = @foo struct {};

Instead, you must put attributes before the type keyword:

library test.good.fi0023;

@foo
type Foo = struct {};

We enforce this because it would be confusing to allow attributes in two places.

fi-0024: Doc comment on method parameter list

Method parameter lists cannot carry doc comments:

library test.bad.fi0024;

protocol Example {
    Method(/// This is a one-way method.
            struct {
        b bool;
    });
};

For the time being, place doc comments on the method itself:

library test.good.fi0024;

protocol Example {
    /// This is a one-way method.
    Method(struct {
        b bool;
    });
};

This error will no longer exist once this bug is resolved. The error a holdover from the migration to describe method payloads using FIDL types, rather than parameter lists.

fi-0025: Imports group must be at top of file

Except for the library declaration at the top of the file, there cannot be any other declarations before the using imports for the file, should they exist:

library test.bad.fi0025;

alias i16 = int16;
using dependent;

type UsesDependent = struct {
    field dependent.Something;
};

To resolve this error, place all of your using imports in a block directly after the library declaration:

library test.good.fi0025;

using dependent;

alias i16 = int16;
type UsesDependent = struct {
    field dependent.Something;
};

This rule reflects a primarily aesthetic decision by the FIDL team that dependencies are easier to read when they are well-grouped and easily located.

fi-0026: Comment inside doc comment block

Comments should not be placed inside of a doc comment block:

library test.bad.fi0026;

/// start
// middle
/// end
type Empty = struct {};

Instead, comments should be placed before or after the doc comment block:

library test.good.fi0026;

// some comments above,
// maybe about the doc comment
/// A
/// multiline
/// comment!
// another comment, maybe about the struct
type Empty = struct {};

Generally, comments immediately preceding the doc comment block are the best place for comments about the doc comment itself.

fi-0027: Blank lines in doc comment block

There should be no blank lines in a doc comment block:

library test.bad.fi0027;

/// start

/// end
type Empty = struct {};

Instead, blank lines should only be placed before or after the doc comment block:

library test.good.fi0027a;

/// A doc comment
type Empty = struct {};

Alternatively, consider omitting the blank lines altogether:

library test.good.fi0027b;

/// A doc comment
type Empty = struct {};

fi-0028: Doc comment must be followed by a declaration

Doc comments are never allowed to be free-floating, like regular comments:

library test.bad.fi0028;

type Empty = struct {};
/// bad

Doc comments must directly precede FIDL declarations in all circumstances:

library test.good.fi0028a;

/// A doc comment
type Empty = struct {};

FIDL "lowers" doc comments to @doc attributes during compilation. In fact, any comment can be written directly in such a manner if so desired:

library test.good.fi0028b;

@doc("An attribute doc comment")
type Empty = struct {};

Standalone doc comments are non-compilable from a technical perspective, but are also confusing semantically: what does it mean to "document" nothing? Unlike regular comments, doc comments get processed into structured documentation, and thus must be clear about which FIDL construct they are attached to.

fi-0029: Resource definition must have at least one property

Resource definitions with no properties specified are prohibited:

library test.bad.resourcedefinitionnoproperties;

resource_definition SomeResource : uint32 {
  properties {};
};

Please specify at least one property:

library test.good.fi0029;

resource_definition SomeResource : uint32 {
    properties {
        subtype strict enum : uint32 {
            NONE = 0;
        };
    };
};

This is an error related to FIDL's internal implementation, and thus should only ever be surfaced to developers working on FIDL's core libraries. End users should never see this error.

The resource_definition declaration it refers to is FIDL's internal means of defining resources like handles, and is likely to change in the future as part of the handle generalization effort.

fi-0030: Invalid modifier

Each FIDL modifier has a specific set of declarations in which it can be used. Using the modifier in a prohibited declaration is not allowed:

library test.bad.fi0030;

type MyStruct = strict struct {
    i int32;
};

The best course of action is to remove the offending modifier:

library test.good.fi0030;

type MyStruct = struct {
    i int32;
};

fi-0031: Only bits and enum can have subtype

Not every FIDL layout can carry a subtype:

library test.bad.fi0031;

type Foo = flexible union : uint32 {};

Only bits and enum layouts are defined over an underlying type.

library test.good.fi0031;

type Foo = flexible enum : uint32 {};

The bits and enum layouts are somewhat unique, in that they are just constrained subtypings of the integral FIDL primitives. Because of this, it makes sense for them to specify an underlying type which acts as this subtype. Conversely, struct, table, and union layouts can be arbitrarily large and can contain many members, therefore a global, layout-wide subtype does not make sense.

fi-0032: Duplicate modifiers disallowed

Specifying the same modifier in a single declaration is prohibited:

library test.bad.fi0032;

type MyUnion = strict resource strict union {
    1: foo bool;
};

Remove the duplicated modifier:

library test.good.fi0032;

type MyUnion = resource strict union {
    1: foo bool;
};

fi-0033: Conflicting modifiers

Certain modifiers are mutually exclusive of one another and cannot both modify the same declaration:

library test.bad.conflictingmodifiers;

type StrictFlexibleFoo = strict flexible union {
    1: b bool;
};

type FlexibleStrictBar = flexible strict union {
    1: b bool;
};

Only one of the strict or flexible modifiers may be used on a single declaration at a time:

library test.good.fi0033;

type FlexibleFoo = flexible union {
    1: i int32;
};

type StrictBar = strict union {
    1: i int32;
};

At this time, only the strict and flexible modifiers are mutually exclusive in this manner. The resource modifier has no reciprocal modifier, and thus has no such restrictions applied to it.

fi-0034: Name collision

Two declarations cannot have the same name:

library test.bad.fi0034;

const COLOR string = "red";
const COLOR string = "blue";

Instead, give each declaration a unique name:

library test.good.fi0034b;

const COLOR string = "red";
const OTHER_COLOR string = "blue";

Alternatively, remove one of the declarations if it was added by mistake:

library test.good.fi0034a;

const COLOR string = "red";

For more information on choosing names, see the FIDL style guide.

fi-0035: Canonical name collision

Two declarations cannot have the same canonical name:

library test.bad.fi0035;

const COLOR string = "red";

protocol Color {};

Even though COLOR and Color look different, they are both represented by the canonical name color. You get the canonical name by converting the original name to snake_case.

To fix the error, give each declaration a name that is unique after canonicalization:

library test.good.fi0035;

const COLOR string = "red";

protocol ColorMixer {};

Following the FIDL style guide's naming guidelines will minimize your chances of running into this error. Canonical name collisions will never happen between declarations that use the same casing style, and they will rarely happen between ones that use different styles because of other requirements (e.g. protocol names should usually be noun phrases ending in -er).

FIDL enforces this rule because bindings generators transform names to the idiomatic naming style for the target language. By ensuring unique canonical names, we guarantee that bindings can do this without producing name collisions. See RFC-0040: Identifier uniqueness for more details.

fi-0036: Name overlap

Declarations with the same name cannot have overlapping availabilities:

@available(added=1)
library test.bad.fi0036;

type Color = strict enum {
    RED = 1;
};

@available(added=2)
type Color = flexible enum {
    RED = 1;
};

Instead, use the @available attribute to make sure only one of the declarations is present at any given version:

@available(added=1)
library test.good.fi0036;

@available(replaced=2)
type Color = strict enum {
    RED = 1;
};

@available(added=2)
type Color = flexible enum {
    RED = 1;
};

Alternatively, rename or remove one of the declarations as shown in fi-0034.

See FIDL versioning to learn more about versioning.

fi-0037: Canonical name overlap

Declarations with the same canonical name cannot have overlapping availabilities:

@available(added=1)
library test.bad.fi0037;

const COLOR string = "red";

@available(added=2)
protocol Color {};

Even though COLOR and Color look different, they are both represented by the canonical name color. You get the canonical name by converting the original name to snake_case.

To fix the error, give each declaration a name that is unique after canonicalization.

@available(added=1)
library test.good.fi0037;

const COLOR string = "red";

@available(added=2)
protocol ColorMixer {};

Alternatively, change one of the declarations availabilities as shown in fi-0036, or remove the declaration.

See fi-0035 for more details on why FIDL requires declarations to have unique canonical names.

fi-0038: Name conflicts with import

A declaration cannot have the same name as a library imported with using:

library dependency;

const VALUE uint32 = 1;

library test.bad.fi0038b;

using dependency;

type dependency = struct {};

// Without this, we'd get fi-0178 instead.
const USE_VALUE uint32 = dependency.VALUE;

Instead, import the library under a different name with the using ... as syntax:

library test.good.fi0038b;

using dependency as dep;

type dependency = struct {};

const USE_VALUE uint32 = dep.VALUE;

Alternatively, rename the declaration to avoid the conflict:

library test.good.fi0038c;

using dependency;

type OtherName = struct {};

const USE_VALUE uint32 = dependency.VALUE;

You can avoid this problem by using multiple components in library names. For example, FIDL libraries in the Fuchsia SDK start with fuchsia., so they have at least two components and cannot conflict with declaration names.

This error exists to prevent ambiguities. For example, if dependency were an enum with a member called VALUE, it would be ambiguous whether dependency.VALUE referred to that enum member or to the const declared in the imported library.

fi-0039: Canonical name conflicts with import

A declaration cannot have the same canonical name as a library import with using:

library dependency;

const VALUE uint32 = 1;

library test.bad.fi0039b;

using dependency;

type Dependency = struct {};

// Without this, we'd get fi-0178 instead.
const USE_VALUE uint32 = dependency.VALUE;

Even though dependency and Dependency look different, they are both represented by the canonical name dependency. You get the canonical name by converting the original name to snake_case.

To fix the error, import the library under a different name with the using ... as syntax:

library test.good.fi0039b;

using dependency as dep;

type Dependency = struct {};

const USE_VALUE uint32 = dep.VALUE;

Alternatively, rename the declaration to avoid the conflict:

library test.good.fi0039c;

using dependency;

type OtherName = struct {};

const USE_VALUE uint32 = dependency.VALUE;

See fi-0038 to learn why this error exists and how to avoid it.

See fi-0035 for more details on why FIDL requires declarations to have unique canonical names.

fi-0040: Files disagree on library name

Libraries can be composed of multiple files, but each file must have the same name:

library test.bad.fi0040a;

library test.bad.fi0040b;

Ensure that all files used by a library share the same name:

library test.good.fi0040;

library test.good.fi0040;

An encouraged convention for multi-file libraries is to create an otherwise empty overview.fidl file to serve as the main "entry point" into the library. The overview.fidl file is also the appropriate place to put library-scoped @available platform specifications.

fi-0041: Multiple libraries with same name

Each library passed to fidlc must have a unique name:

library test.bad.fi0041;

library test.bad.fi0041;

Ensure that all libraries have unique names:

library test.good.fi0041a;

library test.good.fi0041b;

This error is often caused by arguments being supplied to fidlc in an incorrect manner. The constituent files that make up each library necessary for compilation (that is, the library being compiled and all of its transitive dependencies) must be supplied as a single space-separated list of files passed via the --files argument, with one such flag per library. A common mistake is to try to pass the file for all libraries in a single --files list.

fi-0042: Duplicate library import

Dependencies cannot be imported multiple times:

library test.bad.fi0042a;

type Bar = struct {};

library test.bad.fi0042b;

using test.bad.fi0042a;
using test.bad.fi0042a; // duplicated
type Foo = struct {
    bar test.bad.fi0042a.Bar;
};

Ensure that each dependency is only imported once:

library test.good.fi0042a;

type Bar = struct {};

library test.good.fi0042b;

using test.good.fi0042a;
type Foo = struct {
    bar test.good.fi0042a.Bar;
};

It is worth noting that FIDL does not support importing different versions of the same library. The @available version is resolved for the entire fidlc compilation via the --available flag, meaning that both the library being compiled and all of its dependencies must share the same version for any given compilation run.

fi-0043: Conflicting library imports

Imported libraries are prohibited from being aliased in such a way that they conflict with the non-aliased names of other imported libraries:

library test.bad.fi0043a;

type Bar = struct {};

// This library has a one component name to demonstrate the error.
library fi0043b;

type Baz = struct {};

library test.bad.fi0043c;

using test.bad.fi0043a as fi0043b; // conflict
using fi0043b;

type Foo = struct {
    a fi0043b.Bar;
    b fi0043b.Baz;
};

Choose a different alias to resolve the name conflict:

library test.good.fi0043a;

type Bar = struct {};

library fi0043b;

type Baz = struct {};

library test.good.fi0043c;

using test.good.fi0043a as dep;
using fi0043b;

type Foo = struct {
    a dep.Bar;
    b fi0043b.Baz;
};

fi-0044: Conflicting library import aliases

Imported libraries are prohibited from being aliased in such a way that they conflict with the aliases assigned to other imported libraries:

library test.bad.fi0044a;

type Bar = struct {};

library test.bad.fi0044b;

type Baz = struct {};

library test.bad.fi0044c;

using test.bad.fi0044a as dep;
using test.bad.fi0044b as dep; // conflict
type Foo = struct {
    a dep.Bar;
    b dep.Baz;
};

Choose non-conflicting aliases to resolve the name conflict:

library test.good.fi0044a;

type Bar = struct {};

library test.good.fi0044b;

type Baz = struct {};

library test.good.fi0044c;

using test.good.fi0044a as dep1;
using test.good.fi0044b as dep2;
type Foo = struct {
    a dep1.Bar;
    b dep2.Baz;
};

fi-0045: Attributes disallowed on using declarations

Attributes cannot be attached to using declarations:

library test.bad.fi0045a;

type Bar = struct {};

library test.bad.fi0045b;

/// not allowed
@also_not_allowed
using test.bad.fi0045a;

type Foo = struct {
    bar test.bad.fi0045a.Bar;
};

Remove the attribute to resolve the error:

library test.good.fi0045a;

type Bar = struct {};

library test.good.fi0045b;

using test.good.fi0045a;

type Foo = struct {
    bar test.good.fi0045a.Bar;
};

This restriction applies to /// ... doc comments as well, as those are merely syntactic sugar for the @doc("...") attribute.

fi-0046: Unknown library

In most cases, this problem is due to the dependency being misspelled or not provided by the build system. If the dependency in question is intentionally unused, the relevant using line must be removed:

library test.bad.fi0046;

using dependent; // unknown using.

type Foo = struct {
    dep dependent.Bar;
};

Make sure all imports are added as dependencies to the library using the build system.

library test.good.fi0046;

type Foo = struct {
    dep int64;
};

fi-0047

fi-0048: Optional table member

Table members types cannot be optional:

library test.bad.fi0048;

type Foo = table {
    // Strings can be optional in general, but not in table member position.
    1: t string:optional;
};

Remove the optional constraint from all members:

library test.good.fi0048;

type Foo = table {
    1: t string;
};

Table members are always optional, so specifying this fact on the member's underlying type is redundant.

Table members are always optional because, on the wire, each table member is represented as an entry in a vector. This vector is always represents all known fields on the table, so every omitted table member is represented as a null envelope - exactly equivalent to the representation of an omitted optional type.

fi-0049: Optional union member

Union members cannot be optional:

library test.bad.fi0049;

type Foo = strict union {
    // Strings can be optional in general, but not in unions.
    1: bar string:optional;
};

Remove the optional constraint:

library test.good.fi0049;

type Foo = strict union {
    1: bar string;
};

FIDL does not allow union members to be optional because this can result in many ways of expressing the same value. For example, a union with three optional members would have 6 states (2 per member). Instead, this should be modeled with a fourth member whose type is struct {}, or by making the overall union optional with Foo:optional.

fi-0050: Deprecated struct default syntax prohibited

Previously, FIDL allowed for default values to be set on struct members:

library test.bad.fi0050;

type MyStruct = struct {
    field int64 = 20;
};

As of RFC-0160: Remove support for FIDL struct defaults, this behavior is disallowed:

library test.good.fi0050;

type MyStruct = struct {
    field int64;
};

Default values for struct members are no longer allowed. Users should set such defaults in application logic instead.

A small number of legacy users of this syntax are allowed to continue using it behind an allowlist built into the compiler, but no new exceptions are being made to add to this list. As soon as these users are migrated off, this feature will be permanently removed from FIDL.

fi-0051: Unknown dependent library

This error occurs when you use a symbol that's from an unknown library.

library test.bad.fi0051;

type Company = table {
    1: employees vector<unknown.dependent.library.Person>;
    2: name string;
};

To fix this, import the missing dependent library with a using declaration.

library known.dependent.library;

type Person = table {
    1: age uint8;
    2: name string;
};

library test.good.fi0051;
using known.dependent.library;

type Company = table {
    1: employees vector<known.dependent.library.Person>;
    2: name string;
};

This error commonly occurs when the fidlc command line invocation is improperly formed. If you are confident that the unknown library exists and should be resolvable, make sure you are passing the dependent library's files correctly via a space-separated list passed to the --files flag.

fi-0052: Name not found

This error occurs when you use a name that the FIDL compiler cannot find.

library test.bad.fi0052;

protocol Parser {
    Tokenize() -> (struct {
        tokens vector<string>;
    }) error ParsingError; // ParsingError doesn't exist.
};

To fix this, either remove the name that's not found:

library test.good.fi0052a;

protocol Parser {
    Tokenize() -> (struct {
        tokens vector<string>;
    });
};

or define the name that's not found:

library test.good.fi0052b;

type ParsingError = flexible enum {
    UNEXPECTED_EOF = 0;
};

protocol Parser {
    Tokenize() -> (struct {
        tokens vector<string>;
    }) error ParsingError;
};

fi-0053: Cannot refer to member

This error occurs when you refer to a member that's not a bits or enum entry.

library test.bad.fi0053a;

type Person = struct {
    name string;
    birthday struct {
        year uint16;
        month uint8;
        day uint8;
    };
};

const JOHNS_NAME Person.name = "John Johnson"; // Cannot refer to member of struct 'Person'.

library test.bad.fi0053b;

type Person = struct {
    name string;
    birthday struct {
        year uint16;
        month uint8;
        day uint8;
    };
};

type Cat = struct {
    name string;
    age Person.birthday; // Cannot refer to member of struct 'Person'.
};

To fix this error, either change to a named type:

library test.good.fi0053a;

type Person = struct {
    name string;
    birthday struct {
        year uint16;
        month uint8;
        day uint8;
    };
};

const JOHNS_NAME string = "John Johnson";

or extract the member's type:

library test.good.fi0053b;

type Date = struct {
    year uint16;
    month uint8;
    day uint8;
};

type Person = struct {
    name string;
    birthday Date;
};

type Cat = struct {
    name string;
    age Date;
};

fi-0054: Invalid bits/enum member

This error occurs when an enum or bits member is referenced without being previously defined.

library test.bad.fi0054;

type Enum = enum {
    foo_bar = 1;
};

const EXAMPLE Enum = Enum.FOO_BAR;

To avoid this error, confirm that you have previously declared a value for the referenced member value. These values are case sensitive.

library test.good.fi0054;

type Enum = enum {
    foo_bar = 1;
};

const EXAMPLE Enum = Enum.foo_bar;

fi-0055: Invalid reference to deprecated

This error occurs when you use a reference to a type or const a with an incompatible @available attribute. This typically happens when using deprecated types or consts from later versions.

@available(added=1)
library test.bad.fi0055;

@available(added=1, deprecated=2, note="use Color instead")
alias RGB = array<uint8, 3>;

@available(added=2)
type Color = struct {
    r uint8;
    g uint8;
    b uint8;
    a uint8;
};

@available(added=3)
type Config = table {
    // RGB is deprecated in version 2.
    1: color RGB;
};

To fix this error, use a non-deprecated type or const:

@available(added=1)
library test.good.fi0055;

@available(added=1, deprecated=2, note="use Color instead")
alias RGB = array<uint8, 3>;

@available(added=2)
type Color = struct {
    r uint8;
    g uint8;
    b uint8;
    a uint8;
};

@available(added=3)
type Config = table {
    // Using a non-deprecated type.
    1: color Color;
};

fi-0056: Invalid reference to deprecated other platform

This error occurs when you use a reference to a type or const from another platform with an incompatible @available attribute. This typically happens when using deprecated types or consts from later versions.

@available(platform="foo", added=1)
library test.bad.fi0056a;

@available(added=1, deprecated=2, note="use Color instead")
alias RGB = array<uint8, 3>;

@available(added=2)
type Color = struct {
    r uint8;
    g uint8;
    b uint8;
    a uint8;
};

@available(platform="bar", added=2)
library test.bad.fi0056b;

using test.bad.fi0056a;

@available(added=3)
type Config = table {
    // RGB is deprecated in version 2.
    1: color test.bad.fi0056a.RGB;
};

To fix this error, use a non-deprecated type or const:

@available(platform="foo", added=1)
library test.good.fi0056a;

@available(added=1, deprecated=2, note="use Color instead")
alias RGB = array<uint8, 3>;

@available(added=2)
type Color = struct {
    r uint8;
    g uint8;
    b uint8;
    a uint8;
};

@available(platform="bar", added=2)
library test.good.fi0056b;

using test.good.fi0056a;

@available(added=2)
type Config = table {
    // Change to use a non-deprecated type.
    1: color test.good.fi0056a.Color;
};

fi-0057: Includes cycle

There are a number of situations that could cause this problem to occur, but all of them basically boil down to a FIDL declaration referring to itself in an unresolvable way. The simplest form of this error is when a type or protocol refers directly to itself in its own definition:

library test.bad.fi0057c;

type MySelf = struct {
    me MySelf;
};

More complex failure cases are possible when a type or protocol transitively refers to itself via at least one level of indirection:

library test.bad.fi0057a;

type Yin = struct {
    yang Yang;
};

type Yang = struct {
    yin Yin;
};

library test.bad.fi0057b;

protocol Yin {
    compose Yang;
};

protocol Yang {
    compose Yin;
};

This error can be resolved by adding an envelope (aka, optionality) somewhere in the inclusion cycle, as this allows the cycle to be "broken" at encode/decode time:

library test.good.fi0057;

type MySelf = struct {
    me box<MySelf>;
};

library test.bad.fi0057d;

type MySelf = table {
    1: me MySelf;
};

Recursive types that are unbroken by envelopes are disallowed because they would be impossible to encode. In the first example above, encoding MySelf would require first encoding an instance of MySelf, which would in turn require encoding an instance of MySelf, ad inifitum. A solution to this problem is to add a "break" in this chain via optionality, where one may choose to either encode another nested instance of MySelf, or otherwise encode a null envelope with no further data.

fi-0058: Reference to compiler generated payload name

Anonymous method payloads have their names automatically generated by the FIDL compiler, so that users of generated backend code may refer to the types they represent as necessary. Referring to these types in *.fidl files themselves, however, is forbidden:

library test.bad.fi0058;

protocol MyProtocol {
    strict MyInfallible(struct {
        in uint8;
    }) -> (struct {
        out int8;
    });
    strict MyFallible(struct {
        in uint8;
    }) -> (struct {
        out int8;
    }) error flexible enum {};
    strict -> MyEvent(struct {
        out int8;
    });
};

type MyAnonymousReferences = struct {
    a MyProtocolMyInfallibleRequest;
    b MyProtocolMyInfallibleResponse;
    c MyProtocolMyFallibleRequest;
    d MyProtocol_MyFallible_Result;
    e MyProtocol_MyFallible_Response;
    f MyProtocol_MyFallible_Error;
    g MyProtocolMyEventRequest;
};

If you wish to refer to the payload type directly, you should extract the payload type into its own named type declaration instead:

library test.good.fi0058;

type MyRequest = struct {
    in uint8;
};
type MyResponse = struct {
    out int8;
};
type MyError = flexible enum {};

protocol MyProtocol {
    strict MyInfallible(MyRequest) -> (MyResponse);
    strict MyFallible(MyRequest) -> (MyResponse) error MyError;
    strict -> MyEvent(MyResponse);
};

type MyAnonymousReferences = struct {
    a MyRequest;
    b MyResponse;
    c MyRequest;
    // There is no way to explicitly name the error result union.
    // d MyProtocol_MyFallible_Result;
    e MyResponse;
    f MyError;
    g MyResponse;
};

All FIDL methods and events reserve the [PROTOCOL_NAME][METHOD_NAME]Request name for their anonymous request payloads. Strict, infallible two-way methods additionally reserve [PROTOCOL_NAME][METHOD_NAME]Response. Two-way methods that are flexible or fallible instead reserve:

• [PROTOCOL_NAME]_[METHOD_NAME]_Result
• [PROTOCOL_NAME]_[METHOD_NAME]_Response
• [PROTOCOL_NAME]_[METHOD_NAME]_Error

These names use underscores unlike the others for historical reasons.

fi-0059: Invalid constant type

Not all types can used in const declarations:

library test.bad.fi0059;

const MY_CONST string:optional = "foo";

Convert to an allowed type, if possible:

library test.good.fi0059;

const MY_CONST string = "foo";

Only FIDL primitives (bool, int8, int16, int32, int64, uint8, uint16, uint32, uint64, float32, float64) and non-optional string types may be used in the left-hand side of a const declaration.

fi-0060: Cannot resolve constant value

Constant values must be resolvable to known values:

library test.bad.fi0060;

const MY_CONST bool = optional;

Make sure that the constant being used is a valid value:

library test.good.fi0060;

const MY_CONST bool = true;

This error often accompanies other errors, which provide more information on the nature of the non-resolvable expected constant.

fi-0061: Or operator on non-primitive values

The binary-or operator can only be used on primitives:

library test.bad.fi0061;

const HI string = "hi";
const THERE string = "there";
const OR_OP string = HI | THERE;

Try representing the data being operated on as a bits enumeration instead:

library test.good.fi0061;

type MyBits = flexible bits {
    HI = 0x1;
    THERE = 0x10;
};
const OR_OP MyBits = MyBits.HI | MyBits.THERE;

fi-0062: Newtypes are not allowed

Newtypes from RFC-0052: Type aliasing and new types are not fully implementented and cannot be used yet:

library test.bad.fi0062;

type Matrix = array<float64, 9>;

In the meantime, you can achieve something similar by defining a struct with a single element:

library test.good.fi0062a;

type Matrix = struct {
    elements array<float64, 9>;
};

Alternatively, you can define an alias, but note that unlike a newtype this provides no type safety (that is, it can be used interchangeably with its underlying type):

library test.good.fi0062b;

alias Matrix = array<float64, 9>;

fi-0063: Expected value but got type

The right-hand side of a const declaration must resolve to a constant value, not a type:

library test.bad.fi0063;

type MyType = struct {};
const MY_CONST uint32 = MyType;

Ensure that the right-hand side is a value:

library test.good.fi0063;

const MY_VALUE uint32 = 8;
const MY_CONST uint32 = MY_VALUE;

fi-0064: Incorrect bits or enum value type

When using a bits or enum variant as the value in a const declaration, the type of the bits/enum value must be the same as the left-hand side of the const declaration:

library test.bad.fi0064;

type MyEnum = enum : int32 {
    VALUE = 1;
};
type OtherEnum = enum : int32 {
    VALUE = 5;
};
const MY_CONST MyEnum = OtherEnum.VALUE;

One solution is to change the const declaration's type to match that of the value being stored:

library test.good.fi0064;

type MyEnum = enum : int32 {
    VALUE = 1;
};
type OtherEnum = enum : int32 {
    VALUE = 5;
};
const MY_CONST OtherEnum = OtherEnum.VALUE;

Alternatively, a different value can be selected to match the const declaration's type:

library test.good.fi0064;

type MyEnum = enum : int32 {
    VALUE = 1;
};
type OtherEnum = enum : int32 {
    VALUE = 5;
};
const MY_CONST MyEnum = MyEnum.VALUE;

fi-0065: Cannot convert value to expected type

A constant value must be of a type appropriate for the location it is being used.

The most common cause for this error is when a const declaration's value does not match its stated type:

library test.bad.fi0065a;

const MY_CONST bool = "foo";

This can still be problematic when a correctly defined const value is used in a location where its underlying type is invalid:

library test.bad.fi0065b;

const ONE uint8 = 0x0001;
const TWO_FIFTY_SIX uint16 = 0x0100;
const TWO_FIFTY_SEVEN uint8 = ONE | TWO_FIFTY_SIX;

Additionally, FIDL's official check their arguments against a schema. Because these arguments are themselves constant values, the same kind of type mismatch can occur:

library test.bad.fi0065c;

protocol MyProtocol {
    @selector(3840912312901827381273)
    MyMethod();
};

In all of these cases, the solution is to use only use values of the expected type in locations where const values are accepted. The above cases become, respectively:

library test.good.fi0065a;

const MY_CONST string = "foo";

library test.good.fi0065b;

const ONE uint8 = 0x0001;
const TWO_FIFTY_SIX uint16 = 0x0100;
const TWO_FIFTY_SEVEN uint16 = ONE | TWO_FIFTY_SIX;

library test.good.fi0065c;

protocol MyProtocol {
    @selector("MyOldMethod")
    MyMethod();
};

fi-0066: Constant overflows type

A constant value cannot fall outside of the range inherent to its underlying type:

library test.bad.fi0066;

const NUM uint64 = -42;

The problem may be fixed either by changing the value to fit within the type's range:

library test.good.fi0066a;

const NUM uint64 = 42;

Or otherwise by changing to the type to accommodate the currently overflowing value:

library test.good.fi0066b;

const NUM int64 = -42;

This error exclusively concerns FIDL's numeric types, all of which have the capacity to overflow. The ranges are sourced from the C++ std::numeric_limits interface and are as follows:

fi-0067: Bits member must be power of two

The values of all members in a bits declaration must not be any number that is not a power of two:

library test.bad.fi0067;

type NonPowerOfTwo = bits : uint64 {
    THREE = 3;
};

Instead, member values should always be powers of two:

library test.good.fi0067a;

type Fruit = bits : uint64 {
    ORANGE = 1;
    APPLE = 2;
    BANANA = 4;
};

An easy way to avoid getting tripped up by this restriction is to just use bit masks, rather than decimal numbers, for bit member values:

library test.good.fi0067b;

type Life = bits {
    A = 0b000010;
    B = 0b001000;
    C = 0b100000;
};

The bits construct represents a bit array. This is the most memory-efficient way to represent a sequence of boolean flags. Because each member of the bits declaration is mapped to a specific bit of its underlying memory, the values used for that mapping must clearly identify a specific bit in an unsigned integer to assign to.

fi-0068: Flexible enums have a reserved unknown value

This error happens when you define an enum member whose value clashes with the reserved unknown value.

Flexible enums may hold values not known by the FIDL schema. In addition, flexible enums always reserve some value which will be treated as unknown. By default, that value is the maximum numerical value representable by the underlying integer type of that enum (e.g. 255 in case of uint8).

library test.bad.fi0068;

type Foo = flexible enum : uint8 {
    ZERO = 0;
    ONE = 1;
    MAX = 255;
};

To fix the error, you may remove the member or change its value:

library test.good.fi0068a;

type Foo = flexible enum : uint8 {
    ZERO = 0;
    ONE = 1;
};

library test.good.fi0068b;

type Foo = flexible enum : uint8 {
    ZERO = 0;
    ONE = 1;
    MAX = 254;
};

Finally, if you come across this error when transitioning a strict enum to a flexible enum, you may use the @unknown attribute to designate the numerical value of a particular member as the unknown value. See @unknown.

fi-0069: Bits must use unsigned integral subtype

Using signed numerics as the underlying type for a bits declaration is prohibited:

library test.bad.fi0069;

type Fruit = bits : int64 {
    ORANGE = 1;
    APPLE = 2;
    BANANA = 4;
};

Instead, use any one of the following: uint8, uint16, uint32, or uint64:

library test.good.fi0069;

type Fruit = bits : uint64 {
    ORANGE = 1;
    APPLE = 2;
    BANANA = 4;
};

Unlike enum declarations, which allow both signed and unsigned integers (see: fi-0070), bits declarations only permit the latter. This is because each bits member necessarily represents a specific underlying bit in a bit array (this is the reason that fi-0067 exists). This is most cleanly represented as a single unsigned integer. The binary representation of unsigned integer maps directly to a single bit (2 to the power of its index), whereas the negative numbers in signed integers almost always select multiple bits due to the mechanics of the two's complement representation.

fi-0070: Enum must use integral subtype

Using the non-integral numerics float32 or float64 as the underlying type for an enum declaration is prohibited:

library test.bad.fi0070;

type MyEnum = enum : float64 {
    ONE_POINT_FIVE = 1.5;
};

Instead, use any one of the following: int8, int16,int32,int64, uint8, uint16, uint32, or uint64:

library test.good.fi0070;

type MyEnum = enum : uint64 {
    ONE = 1;
};

fi-0071: Unknown attribute disallowed on strict enum members

A strict enum must not have any members annotated with the @unknown attribute:

library test.bad.fi0071;

type MyEnum = strict enum : int8 {
    @unknown
    UNKNOWN = 0;
    FOO = 1;
    MAX = 127;
};

To continue using the @unknown attribute, change to a flexible enum:

library test.good.fi0071a;

type MyEnum = flexible enum : int8 {
    @unknown
    UNKNOWN = 0;
    FOO = 1;
    MAX = 127;
};

Otherwise, just remove the attribute altogether to remain a strict enum:

library test.good.fi0071;

type MyEnum = strict enum : int8 {
    UNKNOWN = 0;
    FOO = 1;
    MAX = 127;
};

The purpose of the @unknown attribute is to smooth over a transition from a strict enum with a user-defined unknown value, like this into a flexible enum with unknown values known to and handled by FIDL. In the above example, it would be used to transition from the second correct usage to the first one.

fi-0072: Only enum member can carry the unknown attribute

Adorning multiple enum members with the @unknown attribute is prohibited:

library test.bad.fi0072;

type MyEnum = flexible enum : uint8 {
    @unknown
    UNKNOWN = 0;
    @unknown
    OTHER = 1;
};

Choose and annotate only the member that is used as a domain specific "unknown" value:

library test.good.fi0071a;

type MyEnum = flexible enum : int8 {
    @unknown
    UNKNOWN = 0;
    OTHER = 1;
};

The purpose of the @unknown attribute is to smooth over a transition from a strict enum with a user-defined unknown value, like this into a flexible enum with unknown values known to and handled by FIDL:

library test.good.fi0072;

type MyEnum = strict enum : int8 {
    UNKNOWN = 0;
    OTHER = 1;
};

library test.good.fi0071a;

type MyEnum = flexible enum : int8 {
    @unknown
    UNKNOWN = 0;
    OTHER = 1;
};

fi-0073: Composing non-protocol

Only protocols can be used in compose statements:

library test.bad.fi0073;

type MyStruct = struct {};

protocol MyProtocol {
    compose MyStruct;
};

Make sure the name you are referring to points to a protocol:

library test.good.fi0073;

protocol MyOtherProtocol {};

protocol MyProtocol {
    compose MyOtherProtocol;
};

fi-0074: Invalid layout used for method payload

Only struct, table, or union layouts may be used to describe method payloads:

library test.bad.fi0074;

protocol MyProtocol {
    MyMethod(enum {
        FOO = 1;
    });
};

Use one of those layouts instead:

library test.good.fi0074;

protocol MyProtocol {
    MyMethod(struct {
        foo bool;
    });
};

fi-0075: Invalid primitive used for method payload

Primitives cannot be used as method method payload:

library test.bad.fi0075;

protocol MyProtocol {
    MyMethod(uint32);
};

Use a type of the struct, table, or union layout instead:

library test.good.fi0075;

protocol MyProtocol {
    MyMethod(struct {
        wrapped_in_struct uint32;
    });
};

For cases where the desirable payload really is just a primitive value, and future evolution is not a concern, wrapping the value in a struct layout will result in a payload that is the same size as desired value is by itself.

fi-0076

fi-0077: Interaction payload cannot be empty struct

The payloads in a method or event cannot be empty structs:

library test.bad.fi0077a;

protocol Test {
    MyMethod(struct {}) -> (struct {});
};

library test.bad.fi0077b;

protocol Test {
    -> MyEvent(struct {});
};

If you would like to express that a particular request/response does not hold any information, delete the empty struct, leaving () in that location:

library test.good.fi0077a;

protocol Test {
    MyMethod() -> ();
};

library test.good.fi0077b;

protocol Test {
    -> MyEvent();
};

Empty structs cannot be extended, and take 1 byte on the wire. Since FIDL supports interactions without payloads, using empty structs this way is superfluous and less efficient. Therefore they are not allowed.

fi-0078

fi-0079

fi-0080: Generated zero value ordinal

This error should never occur. If you managed to make it happen, congratulations, you've probably broken SHA-256!

Joking aside, this error occurs if the fidlc compiler generates an ordinal value of 0. It should never happen, so if it does, you've probably found a bug in the FIDL compiler. Please report the issue to our issue tracker if this happens.

fi-0081: Duplicate method ordinal

This error usually occurs when you use an @selector attribute to make two method names produce the same ordinal.

library test.bad.fi0081;

protocol Parser {
    ParseLine();

    // Multiple methods with the same ordinal...
    @selector("ParseLine")
    ParseOneLine();
};

To fix this issue, update either the method names, or selectors to not collide.

library test.good.fi0081;

protocol Parser {
    ParseLine();

    @selector("Parse1Line")
    ParseOneLine();
};

This error can also happen if there is a SHA-256 collision, but the chances of this are basically zero. If you are positive your selectors aren't at fault and you still run into this error, you've probably found a bug in the FIDL compiler. Please report the issue to our issue tracker if this happens.

fi-0082: Invalid selector value

This error occurs when you use an invalid value for an @selector. Most commonly, this is due to a typo. A selector must either be a standalone method name, or a fully qualified method name.

library test.bad.fi0082;

protocol Parser {
    @selector("test.old.fi0082.Parser.Parse")
    Parse();
};

To fix this, update the selector to either be a valid standalone, or fully qualified method name:

library test.good.fi0082;

protocol Parser {
    @selector("test.old.fi0082/Parser.Parse")
    Parse();
};

fi-0083: fuchsia.io must use explicit ordinals

The FIDL compiler used to automatically rename fuchsia.io ordinals to fuchsia.io1. This magic was intended to make it easier to migrate to fuchsia.io2 by letting the io2 versions of the methods have the "normal" ordinal. However, this system ended up being a bit too magical so it is now required to manually provide the ordinal for fuchsia.io.

library fuchsia.io;

protocol SomeProtocol {
    SomeMethod();
};

To fix this issue, manually provide a selector using fuchsia.io1 as the library name to allow the fuchsia.io names to be used for io2.

library fuchsia.io;

protocol SomeProtocol {
    @selector("fuchsia.io1/SomeProtocol.SomeMethod")
    SomeMethod();
};

fi-0084: Default members disallowed on method payload structs

Structs used as method paylods may not specify default members:

library test.bad.fi0084;

type MyStruct = struct {
    @allow_deprecated_struct_defaults
    a bool = false;
};

protocol MyProtocol {
    MyMethod(MyStruct) -> (MyStruct);
};

Remove the default members from the relevant struct declaration:

library test.good.fi0084;

type MyStruct = struct {
    a bool;
};

protocol MyProtocol {
    MyMethod(MyStruct) -> (MyStruct);
};