[System]
You are a helpful assistant that answers strictly in JSON. Here's the JSON schema you must adhere to:
<schema>
{"$schema":"http://json-schema.org/draft-07/schema#","$id":"https://json.schemastore.org/cargo.json","x-tombi-toml-version":"v1.0.0","definitions":{"Build":{"title":"Build","description":"The `build` field specifies a file in the package root which is a [build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) for building native code. More information can be found in the [build script guide](https://doc.rust-lang.org/cargo/reference/build-scripts.html).\n\n\n```toml\n[package]\n# ...\nbuild = \"build.rs\"\n```\n\nThe default is `\"build.rs\"`, which loads the script from a file named\n`build.rs` in the root of the package. Use `build = \"custom_build_name.rs\"` to\nspecify a path to a different file or `build = false` to disable automatic\ndetection of the build script.\n","anyOf":[{"description":"Path to the build file.","type":"string"},{"type":"boolean","enum":[true,false],"x-taplo":{"docs":{"enumValues":["Automatically detect the build file (`build.rs`).","Disable automatic detection of the build file."]}}}],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-build-field"}}},"DebugLevel":{"title":"Debug Level","description":"The `debug` setting controls the [`-C debuginfo` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#debuginfo) which controls the\namount of debug information included in the compiled binary.","oneOf":[{"type":"string","enum":["none","line-directives-only","line-tables-only","limited","full"]},{"type":"boolean"},{"type":"integer","enum":[0,1,2]}],"x-taplo":{"docs":{"enumValues":["No debug info at all, default for `release` profile","Debug info without type or variable-level information. Generates more detailed module-level info than `line-tables-only`.","Full debug info, default for `dev` profile","Full debug info, default for `dev` profile","No debug info at all, default for `release` profile","No debug info at all, default for `release` profile","Line info directives only. For the nvptx* targets this enables [profiling](https://reviews.llvm.org/D46061). For other use cases, `line-tables-only` is the better, more compatible choice.","Line tables only. Generates the minimal amount of debug info for backtraces with filename/line number info, but not anything else, i.e. no variable or function parameter info.","Debug info without type or variable-level information. Generates more detailed module-level info than `line-tables-only`.","Full debug info, default for `dev` profile"]},"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#debug"}}},"Dependency":{"title":"Dependency","anyOf":[{"$ref":"#/definitions/SemVerRequirement"},{"$ref":"#/definitions/DetailedDependency"}]},"DetailedDependency":{"title":"Detailed Dependency","type":"object","properties":{"workspace":{"description":"Inherit this dependency from the workspace manifest.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace"}}},"version":{"$ref":"#/definitions/SemVerRequirement"},"branch":{"description":"Specify the Git branch to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories"}}},"default-features":{"description":"Use the default features of the dependency.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#choosing-features"}}},"default_features":{"type":"boolean","description":"\"default_features\" is deprecated. Use \"default-features\" instead.","deprecated":true,"x-taplo":{"hidden":true}},"features":{"description":"List of features to activate in the dependency.","type":"array","items":{"description":"List of features to activate in the dependency.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#choosing-features"},"plugins":["crates"],"crates":{"schemas":"feature"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#choosing-features"}}},"git":{"description":"To depend on a library located in a `git` repository, the minimum information\nyou need to specify is the location of the repository with the `git` key:\n\n```toml\n[dependencies]\nrand = { git = \"https://github.com/rust-lang-nursery/rand\" }\n```\n\nCargo will fetch the `git` repository at this location then look for a\n`Cargo.toml` for the requested crate anywhere inside the `git` repository\n(not necessarily at the root - for example, specifying a member crate name\nof a workspace and setting `git` to the repository containing the workspace).\n\nSince we haven't specified any other information, Cargo assumes that\nwe intend to use the latest commit on the main branch to build our package.\nYou can combine the `git` key with the `rev`, `tag`, or `branch` keys to\nspecify something else. Here's an example of specifying that you want to use\nthe latest commit on a branch named `next`:\n\n```toml\n[dependencies]\nrand = { git = \"https://github.com/rust-lang-nursery/rand\", branch = \"next\" }\n```\n\nSee [Git Authentication](https://doc.rust-lang.org/cargo/appendix/git-authentication.html) for help with git authentication for private repos.\n\n> **Note**: [crates.io](https://crates.io/) does not allow packages to be published with `git`\n> dependencies (`git` [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) are ignored). See the [Multiple\n> locations](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations) section for a fallback alternative.\n","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories"}}},"optional":{"description":"Mark the dependency as optional.\n\nOptional dependencies can be activated through features.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#choosing-features"}}},"package":{"description":"Specify the name of the package.\n\nWhen writing a `[dependencies]` section in `Cargo.toml` the key you write for a\ndependency typically matches up to the name of the crate you import from in the\ncode. For some projects, though, you may wish to reference the crate with a\ndifferent name in the code regardless of how it's published on crates.io. For\nexample you may wish to:\n\n* Avoid the need to  `use foo as bar` in Rust source.\n* Depend on multiple versions of a crate.\n* Depend on crates with the same name from different registries.\n\nTo support this Cargo supports a `package` key in the `[dependencies]` section\nof which package should be depended on:\n\n```toml\n[package]\nname = \"mypackage\"\nversion = \"0.0.1\"\n\n[dependencies]\nfoo = \"0.1\"\nbar = { git = \"https://github.com/example/project\", package = \"foo\" }\nbaz = { version = \"0.1\", registry = \"custom\", package = \"foo\" }\n```\n\nIn this example, three crates are now available in your Rust code:\n\n```rust\nextern crate foo; // crates.io\nextern crate bar; // git repository\nextern crate baz; // registry `custom`\n```\n\nAll three of these crates have the package name of `foo` in their own\n`Cargo.toml`, so we're explicitly using the `package` key to inform Cargo that\nwe want the `foo` package even though we're calling it something else locally.\nThe `package` key, if not specified, defaults to the name of the dependency\nbeing requested.\n","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#renaming-dependencies-in-cargotoml"}}},"path":{"description":"Cargo supports **path dependencies** which are typically sub-crates that live within one repository.\nLet's start off by making a new crate inside of our `hello_world` package:\n\n```console\n# inside of hello_world/\n$ cargo new hello_utils\n```\n\nThis will create a new folder `hello_utils` inside of which a `Cargo.toml` and\n`src` folder are ready to be configured. In order to tell Cargo about this, open\nup `hello_world/Cargo.toml` and add `hello_utils` to your dependencies:\n\n```toml\n[dependencies]\nhello_utils = { path = \"hello_utils\" }\n```\n\nThis tells Cargo that we depend on a crate called `hello_utils` which is found\nin the `hello_utils` folder (relative to the `Cargo.toml` it's written in).","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies"}}},"public":{"type":"boolean","x-taplo":{"hidden":true}},"registry":{"description":"To specify a dependency from a registry other than [crates.io](https://crates.io), first the\nregistry must be configured in a `.cargo/config.toml` file. See the [registries\ndocumentation](https://doc.rust-lang.org/cargo/reference/registries.html) for more information. In the dependency, set the `registry` key\nto the name of the registry to use.\n\n```toml\n[dependencies]\nsome-crate = { version = \"1.0\", registry = \"my-registry\" }\n```\n\n> **Note**: [crates.io](https://crates.io) does not allow packages to be published with\n> dependencies on other registries.\n","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-other-registries"}}},"registry-index":{"type":"string","x-taplo":{"hidden":true}},"rev":{"description":"Specify the Git revision to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#choice-of-commit).\n\nThis can be a commit hash, or a named reference exposed by the remote repository. GitHub Pull Requests may be specified using the `refs/pull/ID/head` format.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#choice-of-commit"}}},"tag":{"description":"Specify the Git tag to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories"}}}},"minProperties":1,"additionalProperties":false,"x-tombi-table-keys-order":"schema","x-taplo":{"initFields":["version"]}},"DetailedLint":{"title":"Detailed Lint","type":"object","properties":{"level":{"$ref":"#/definitions/LintLevel"},"priority":{"description":"The priority that controls which lints or [lint groups](https://doc.rust-lang.org/rustc/lints/groups.html) override other lint groups. Lower (particularly negative) numbers have lower priority, being overridden by higher numbers, and show up first on the command-line to tools like rustc.","type":"integer","x-taplo":{"links":{"key":"https://doc.rust-lang.org/stable/cargo/reference/manifest.html#the-lints-section"}}}},"x-tombi-table-keys-order":"version-sort"},"Edition":{"title":"Edition","description":"The `edition` key affects which edition your package is compiled with. Cargo\nwill always generate packages via [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) with the `edition` key set to the\nlatest edition. Setting the `edition` key in `[package]` will affect all\ntargets/crates in the package, including test suites, benchmarks, binaries,\nexamples, etc.","type":"string","enum":["2015","2018","2021","2024"],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/stable/edition-guide/introduction.html"}}},"Inherits":{"title":"Inherits","description":"In addition to the built-in profiles, additional custom profiles can be defined.","type":"string","enum":["dev","test","bench","release"],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#custom-profiles"}}},"Lint":{"title":"Lint","anyOf":[{"$ref":"#/definitions/LintLevel"},{"$ref":"#/definitions/DetailedLint"}]},"LintLevel":{"title":"Lint Level","description":"Specify the [lint level](https://doc.rust-lang.org/rustc/lints/levels.html) for a lint or lint group.","type":"string","enum":["forbid","deny","warn","allow"],"x-taplo":{"docs":{"enumValues":["`forbid` is the same as `deny` in that a lint at this level will produce an error, but unlike the `deny` level, the `forbid` level can not be overridden to be anything lower than an error. However, lint levels may still be capped with [`--cap-lints`](https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints) so `rustc --cap-lints warn` will make lints set to `forbid` just warn.","The `deny` lint level produces an error if you violate the lint.","The `warn` lint level produces a warning if you violate the lint.","The `allow` lint level ignores violations of the lint."]},"links":{"key":"https://doc.rust-lang.org/rustc/lints/levels.html"}}},"Lints":{"type":"object","properties":{"rust":{"description":"Lint settings for the Rust compiler. See the Rust compiler's [individual lints](https://doc.rust-lang.org/rustc/lints/listing/index.html) or [lint groups](https://doc.rust-lang.org/rustc/lints/groups.html).","type":"object","additionalProperties":{"$ref":"#/definitions/Lint"},"x-tombi-table-keys-order":"version-sort"},"rustdoc":{"description":"Lint settings for [Rustdoc](https://doc.rust-lang.org/rustdoc/). See Rustdoc's [individual lints](https://doc.rust-lang.org/rustdoc/lints.html) (rustdoc does not have lint groups)","type":"object","additionalProperties":{"$ref":"#/definitions/Lint"},"x-tombi-table-keys-order":"version-sort"},"clippy":{"description":"Lint settings for [Clippy](https://doc.rust-lang.org/clippy/). See Clippy's [individual lints](https://rust-lang.github.io/rust-clippy/master/index.html) or [lint groups](https://doc.rust-lang.org/clippy/lints.html) documentation.","type":"object","additionalProperties":{"$ref":"#/definitions/Lint"},"x-tombi-table-keys-order":"version-sort"}},"additionalProperties":false,"x-tombi-table-keys-order":"version-sort"},"Lto":{"title":"Lto","description":"The `lto` setting controls the [`-C lto` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#lto) which controls LLVM's [link time optimizations](https://llvm.org/docs/LinkTimeOptimization.html). LTO can produce better optimized code, using\nwhole-program analysis, at the cost of longer linking time.\n                    \nSee also the [`-C linker-plugin-lto`](https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-plugin-lto) `rustc` flag for cross-language LTO.","oneOf":[{"type":"string","enum":["fat","thin","off"]},{"type":"boolean"}],"x-taplo":{"docs":{"enumValues":["Performs \"fat\" LTO which attempts to perform optimizations across all crates within the dependency graph.","Performs [\"thin\" LTO](http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html). This is similar to \"fat\", but takes\nsubstantially less time to run while still achieving performance gains\nsimilar to \"fat\".","Disables LTO.","Performs \"fat\" LTO which attempts to perform optimizations across all crates within the dependency graph.","Performs \"thin local LTO\" which performs \"thin\" LTO on the local\ncrate only across its [codegen units](https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units). No LTO is performed\nif codegen units is 1 or [opt-level](https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level) is 0."]},"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#lto"}}},"MetaBuild":{"title":"Meta Build","type":"array","items":{"type":"string"},"x-tombi-array-values-order":"version-sort"},"Resolver":{"title":"Resolver","description":"A different feature resolver algorithm can be used by specifying the resolver version in Cargo.toml like this:\n\n[package]\nname = \"my-package\"\nversion = \"1.0.0\"\nresolver = \"2\"\n\nThe version \"1\" resolver is the original resolver that shipped with Cargo up to version 1.50. The default is \"2\" if the root package specifies edition = \"2021\" or a newer edition. Otherwise the default is \"1\".\n\nThe version \"2\" resolver introduces changes in feature unification. See the features chapter for more details.\n\nThe resolver is a global option that affects the entire workspace. The resolver version in dependencies is ignored, only the value in the top-level package will be used. If using a virtual workspace, the version should be specified in the [workspace] table, for example:\n\n[workspace]\nmembers = [\"member1\", \"member2\"]\nresolver = \"2\"","type":"string","enum":["1","2","3"],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions"}}},"OptLevel":{"title":"Optimization Level","description":"The `opt-level` setting controls the [`-C opt-level` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#opt-level) which controls the level\nof optimization. Higher optimization levels may produce faster runtime code at\nthe expense of longer compiler times. Higher levels may also change and\nrearrange the compiled code which may make it harder to use with a debugger.\n\nIt is recommended to experiment with different levels to find the right\nbalance for your project. There may be surprising results, such as level `3`\nbeing slower than `2`, or the `\"s\"` and `\"z\"` levels not being necessarily\nsmaller. You may also want to reevaluate your settings over time as newer\nversions of `rustc` changes optimization behavior.\n\nSee also [Profile Guided Optimization](https://doc.rust-lang.org/rustc/profile-guided-optimization.html) for more advanced optimization\ntechniques.","oneOf":[{"type":"string","enum":["s","z"]},{"type":"integer","enum":[0,1,2,3]}],"x-taplo":{"docs":{"enumValues":["No optimizations, also turns on [`cfg(debug_assertions)`](https://doc.rust-lang.org/cargo/reference/profiles.html#debug-assertions).","Basic optimizations.","Some optimizations.","All optimizations.","Optimize for binary size.","Optimize for binary size, but also turn off loop vectorization."]},"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level"}}},"Package":{"title":"Package","description":"The only field required by Cargo is [`name`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-name-field).\n If publishing to a registry, the registry may\nrequire additional fields. See the notes below and [the publishing chapter](https://doc.rust-lang.org/cargo/reference/publishing.html) for requirements for publishing to [crates.io](https://crates.io/).","type":"object","required":["name"],"properties":{"name":{"description":"The package name is an identifier used to refer to the package. It is used\nwhen listed as a dependency in another package, and as the default name of\ninferred lib and bin targets.\n\nThe name must use only [alphanumeric](https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric) characters or `-` or `_`, and cannot be empty.\nNote that [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) and [`cargo init`](https://doc.rust-lang.org/cargo/commands/cargo-init.html) impose some additional restrictions on\nthe package name, such as enforcing that it is a valid Rust identifier and not\na keyword. [crates.io](https://crates.io) imposes even more restrictions, such as\nenforcing only ASCII characters, not a reserved name, not a special Windows\nname such as \"nul\", is not too long, etc.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-name-field"}}},"version":{"title":"Semantic Version","description":"Cargo bakes in the concept of [Semantic Versioning](https://semver.org/), so make sure you follow some basic rules:\n\n* Before you reach 1.0.0, anything goes, but if you make breaking changes,\n    increment the minor version. In Rust, breaking changes include adding fields to\n    structs or variants to enums.\n* After 1.0.0, only make breaking changes when you increment the major version.\n    Don't break the build.\n* After 1.0.0, don't add any new public API (no new `pub` anything) in patch-level\n    versions. Always increment the minor version if you add any new `pub` structs,\n    traits, fields, types, functions, methods or anything else.\n* Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.","anyOf":[{"$ref":"#/definitions/SemVer"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"authors":{"title":"Authors","description":"The `authors` field lists people or organizations that are considered the\n\"authors\" of the package. The exact meaning is open to interpretation \u2014 it may\nlist the original or primary authors, current maintainers, or owners of the\npackage. These names will be listed on the crate's page on\n[crates.io](https://crates.io). An optional email address may be included within angled\nbrackets at the end of each author.\n\n> **Note**: [crates.io](https://crates.io) requires at least one author to be listed.","anyOf":[{"$ref":"#/definitions/Authors"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"edition":{"title":"Edition","description":"The `edition` key affects which edition your package is compiled with. Cargo\nwill always generate packages via [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) with the `edition` key set to the\nlatest edition. Setting the `edition` key in `[package]` will affect all\ntargets/crates in the package, including test suites, benchmarks, binaries,\nexamples, etc.","anyOf":[{"$ref":"#/definitions/Edition"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"rust-version":{"title":"RustVersion","description":"The `rust-version` field is an optional key that tells cargo what version of the\nRust language and compiler your package can be compiled with. If the currently\nselected version of the Rust compiler is older than the stated version, cargo\nwill exit with an error, telling the user what version is required.\n\nThe first version of Cargo that supports this field was released with Rust 1.56.0.\nIn older releases, the field will be ignored, and Cargo will display a warning.\n\n```toml\n[package]\n# ...\nrust-version = \"1.56\"\n```\n\nThe Rust version must be a bare version number with two or three components; it\ncannot include semver operators or pre-release identifiers. Compiler pre-release\nidentifiers such as -nightly will be ignored while checking the Rust version.\nThe `rust-version` must be equal to or newer than the version that first\nintroduced the configured `edition`.\n\nThe `rust-version` may be ignored using the `--ignore-rust-version` option.\n\nSetting the `rust-version` key in `[package]` will affect all targets/crates in\nthe package, including test suites, benchmarks, binaries, examples, etc.","anyOf":[{"$ref":"#/definitions/RustVersion"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"description":{"title":"Description","description":"The description is a short blurb about the package. [crates.io](https://crates.io) will display\nthis with your package. This should be plain text (not Markdown).\n\n```toml\n[package]\n# ...\ndescription = \"A short description of my package\"\n```\n\n> **Note**: [crates.io](https://crates.io) requires the `description` to be set.","anyOf":[{"$ref":"#/definitions/Description"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"documentation":{"title":"Documentation","description":"\nThe `documentation` field specifies a URL to a website hosting the crate's\ndocumentation. If no URL is specified in the manifest file, [crates.io](https://crates.io) will\nautomatically link your crate to the corresponding [docs.rs](https://docs.rs) page.\n\n```toml\n[package]\n# ...\ndocumentation = \"https://docs.rs/bitflags\"\n```\n","anyOf":[{"$ref":"#/definitions/Documentation"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"readme":{"title":"Readme","description":"The `readme` field should be the path to a file in the package root (relative\nto this `Cargo.toml`) that contains general information about the package.\nThis file will be transferred to the registry when you publish. [crates.io](https://crates.io)\nwill interpret it as Markdown and render it on the crate's page.\n\n```toml\n[package]\n# ...\nreadme = \"README.md\"\n```\n\nIf no value is specified for this field, and a file named `README.md`,\n`README.txt` or `README` exists in the package root, then the name of that\nfile will be used. You can suppress this behavior by setting this field to\n`false`. If the field is set to `true`, a default value of `README.md` will\nbe assumed.\n","anyOf":[{"$ref":"#/definitions/Readme"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"homepage":{"title":"Homepage","description":"The `homepage` field should be a URL to a site that is the home page for your\npackage.\n\n```toml\n[package]\n# ...\nhomepage = \"https://serde.rs/\"\n```","anyOf":[{"$ref":"#/definitions/Homepage"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"repository":{"title":"Repository","description":"The `repository` field should be a URL to the source repository for your\npackage.\n\n```toml\n[package]\n# ...\nrepository = \"https://github.com/rust-lang/cargo/\"\n```","anyOf":[{"$ref":"#/definitions/Repository"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"license":{"title":"License","description":"The `license` field contains the name of the software license that the package\nis released under.\n\n[crates.io](https://crates.io/) interprets the `license` field as an [SPDX 2.1 license\nexpression](https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60). The name must be a known license\nfrom the [SPDX license list 3.6](https://github.com/spdx/license-list-data/tree/v3.6). Parentheses are not\ncurrently supported. See the [SPDX site](https://spdx.org/license-list) for more information.\n\nSPDX license expressions support AND and OR operators to combine multiple\nlicenses.\n\n```toml\n[package]\n# ...\nlicense = \"MIT OR Apache-2.0\"\n```\n\nUsing `OR` indicates the user may choose either license. Using `AND` indicates\nthe user must comply with both licenses simultaneously. The `WITH` operator\nindicates a license with a special exception. Some examples:\n\n* `MIT OR Apache-2.0`\n* `LGPL-2.1 AND MIT AND BSD-2-Clause`\n* `GPL-2.0+ WITH Bison-exception-2.2`\n\nIf a package is using a nonstandard license, then the `license-file` field may\nbe specified in lieu of the `license` field.","anyOf":[{"$ref":"#/definitions/License"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"license-file":{"title":"LicenseFile","description":"The `license-file` field contains the path to a file\ncontaining the text of the license (relative to this `Cargo.toml`).\n\n```toml\n[package]\n# ...\nlicense-file = \"LICENSE.txt\"\n```\n\n> **Note**: [crates.io](https://crates.io) requires either `license` or `license-file` to be set.","anyOf":[{"$ref":"#/definitions/LicenseFile"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"keywords":{"title":"Keywords","description":"The `keywords` field is an array of strings that describe this package. This\ncan help when searching for the package on a registry, and you may choose any\nwords that would help someone find this crate.\n\n```toml\n[package]\n# ...\nkeywords = [\"gamedev\", \"graphics\"]\n```\n\n> **Note**: [crates.io](https://crates.io) has a maximum of 5 keywords. Each keyword must be\n> ASCII text, start with a letter, and only contain letters, numbers, `_` or\n> `-`, and have at most 20 characters.","anyOf":[{"$ref":"#/definitions/Keywords"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"categories":{"title":"Categories","description":"The `categories` field is an array of strings of the categories this package\nbelongs to.\n\n```toml\ncategories = [\"command-line-utilities\", \"development-tools::cargo-plugins\"]\n```\n\n> **Note**: [crates.io](https://crates.io) has a maximum of 5 categories. Each category should\n> match one of the strings available at https://crates.io/category_slugs, and\n> must match exactly.","anyOf":[{"$ref":"#/definitions/Categories"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"workspace":{"description":"The `workspace` field can be used to configure the workspace that this package\nwill be a member of. If not specified this will be inferred as the first\nCargo.toml with `[workspace]` upwards in the filesystem. Setting this is\nuseful if the member is not inside a subdirectory of the workspace root.\n\n```toml\n[package]\n# ...\nworkspace = \"path/to/workspace/root\"\n```\n\nThis field cannot be specified if the manifest already has a `[workspace]`\ntable defined. That is, a crate cannot both be a root crate in a workspace\n(contain `[workspace]`) and also be a member crate of another workspace\n(contain `package.workspace`).\n\nFor more information, see the [workspaces chapter](https://doc.rust-lang.org/cargo/reference/workspaces.html).","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-workspace-field"}}},"build":{"$ref":"#/definitions/Build"},"links":{"description":"The `links` field specifies the name of a native library that is being linked\nto. More information can be found in the [`links`](https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key) section of the build\nscript guide.\n\n```toml\n[package]\n# ...\nlinks = \"foo\"\n```","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-links-field"}}},"exclude":{"title":"Exclude","description":"You can explicitly specify that a set of file patterns should be ignored or\nincluded for the purposes of packaging. The patterns specified in the\n`exclude` field identify a set of files that are not included, and the\npatterns in `include` specify files that are explicitly included.\n\nThe patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:\n\n- `foo` matches any file or directory with the name `foo` anywhere in the\n  package. This is equivalent to the pattern `**/foo`.\n- `/foo` matches any file or directory with the name `foo` only in the root of\n  the package.\n- `foo/` matches any *directory* with the name `foo` anywhere in the package.\n- Common glob patterns like `*`, `?`, and `[]` are supported:\n  - `*` matches zero or more characters except `/`.  For example, `*.html`\n    matches any file or directory with the `.html` extension anywhere in the\n    package.\n  - `?` matches any character except `/`. For example, `foo?` matches `food`,\n    but not `foo`.\n  - `[]` allows for matching a range of characters. For example, `[ab]`\n    matches either `a` or `b`. `[a-z]` matches letters a through z.\n- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the\n  file or directory `bar` anywhere that is directly under directory `foo`.\n- `/**` suffix matches everything inside. For example, `foo/**` matches all\n  files inside directory `foo`, including all files in subdirectories below\n  `foo`.\n- `/**/` matches zero or more directories. For example, `a/**/b` matches\n  `a/b`, `a/x/b`, `a/x/y/b`, and so on.\n- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and\n  `!foo.rs` would match all files with the `.rs` extension inside the `src`\n  directory, except for any file named `foo.rs`.\n\nIf git is being used for a package, the `exclude` field will be seeded with\nthe `gitignore` settings from the repository.\n\n```toml\n[package]\n# ...\nexclude = [\"build/**/*.o\", \"doc/**/*.html\"]\n```\n\n```toml\n[package]\n# ...\ninclude = [\"src/**/*\", \"Cargo.toml\"]\n```\n\nThe options are mutually exclusive: setting `include` will override an\n`exclude`. Note that `include` must be an exhaustive list of files as otherwise\nnecessary source files may not be included. The package's `Cargo.toml` is\nautomatically included.\n\nThe include/exclude list is also used for change tracking in some situations.\nFor targets built with `rustdoc`, it is used to determine the list of files to\ntrack to determine if the target should be rebuilt. If the package has a\n[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the\ninclude/exclude list is used for tracking if the build script should be re-run\nif any of those files change.","anyOf":[{"$ref":"#/definitions/Exclude"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"include":{"description":"You can explicitly specify that a set of file patterns should be ignored or\nincluded for the purposes of packaging. The patterns specified in the\n`exclude` field identify a set of files that are not included, and the\npatterns in `include` specify files that are explicitly included.\n\nThe patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:\n\n- `foo` matches any file or directory with the name `foo` anywhere in the\n  package. This is equivalent to the pattern `**/foo`.\n- `/foo` matches any file or directory with the name `foo` only in the root of\n  the package.\n- `foo/` matches any *directory* with the name `foo` anywhere in the package.\n- Common glob patterns like `*`, `?`, and `[]` are supported:\n  - `*` matches zero or more characters except `/`.  For example, `*.html`\n    matches any file or directory with the `.html` extension anywhere in the\n    package.\n  - `?` matches any character except `/`. For example, `foo?` matches `food`,\n    but not `foo`.\n  - `[]` allows for matching a range of characters. For example, `[ab]`\n    matches either `a` or `b`. `[a-z]` matches letters a through z.\n- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the\n  file or directory `bar` anywhere that is directly under directory `foo`.\n- `/**` suffix matches everything inside. For example, `foo/**` matches all\n  files inside directory `foo`, including all files in subdirectories below\n  `foo`.\n- `/**/` matches zero or more directories. For example, `a/**/b` matches\n  `a/b`, `a/x/b`, `a/x/y/b`, and so on.\n- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and\n  `!foo.rs` would match all files with the `.rs` extension inside the `src`\n  directory, except for any file named `foo.rs`.\n\nIf git is being used for a package, the `exclude` field will be seeded with\nthe `gitignore` settings from the repository.\n\n```toml\n[package]\n# ...\nexclude = [\"build/**/*.o\", \"doc/**/*.html\"]\n```\n\n```toml\n[package]\n# ...\ninclude = [\"src/**/*\", \"Cargo.toml\"]\n```\n\nThe options are mutually exclusive: setting `include` will override an\n`exclude`. Note that `include` must be an exhaustive list of files as otherwise\nnecessary source files may not be included. The package's `Cargo.toml` is\nautomatically included.\n\nThe include/exclude list is also used for change tracking in some situations.\nFor targets built with `rustdoc`, it is used to determine the list of files to\ntrack to determine if the target should be rebuilt. If the package has a\n[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the\ninclude/exclude list is used for tracking if the build script should be re-run\nif any of those files change.","anyOf":[{"$ref":"#/definitions/Include"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"publish":{"title":"Publish","description":"The `publish` field can be used to prevent a package from being published to a package registry (like *crates.io*) by mistake, for instance to keep a package\nprivate in a company.\n\n```toml\n[package]\n# ...\npublish = false\n```\n\nThe value may also be an array of strings which are registry names that are\nallowed to be published to.\n\n```toml\n[package]\n# ...\npublish = [\"some-registry-name\"]\n```","anyOf":[{"$ref":"#/definitions/Publish"},{"$ref":"#/definitions/WorkspaceInheritance"}]},"metadata":{"description":"Cargo by default will warn about unused keys in `Cargo.toml` to assist in\ndetecting typos and such. The `package.metadata` table, however, is completely\nignored by Cargo and will not be warned about. This section can be used for\ntools which would like to store package configuration in `Cargo.toml`. For\nexample:\n\n```toml\n[package]\nname = \"...\"\n# ...\n\n# Metadata used when generating an Android APK, for example.\n[package.metadata.android]\npackage-name = \"my-awesome-android-app\"\nassets = \"path/to/static\"\n```\n","type":"object","additionalProperties":true,"properties":{"playdate":{"$ref":"#/definitions/PlaydateMetadata"}},"x-tombi-table-keys-order":"schema","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-metadata-table"}}},"default-run":{"description":"The `default-run` field in the `[package]` section of the manifest can be used\nto specify a default binary picked by [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html). For example, when there is\nboth `src/bin/a.rs` and `src/bin/b.rs`:\n\n```toml\n[package]\ndefault-run = \"a\"\n```","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-default-run-field"}}},"autobins":{"description":"Disable automatic discovery of `bin` targets.\n\nDisabling automatic discovery should only be needed for specialized\nsituations. For example, if you have a library where you want a *module* named\n`bin`, this would present a problem because Cargo would usually attempt to\ncompile anything in the `bin` directory as an executable. Here is a sample\nlayout of this scenario:\n\n```\n\u251c\u2500\u2500 Cargo.toml\n\u2514\u2500\u2500 src\n    \u251c\u2500\u2500 lib.rs\n    \u2514\u2500\u2500 bin\n        \u2514\u2500\u2500 mod.rs\n```\n\nTo prevent Cargo from inferring `src/bin/mod.rs` as an executable, set\nthis to `false` to disable auto-discovery.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery"}}},"autoexamples":{"description":"Disable automatic discovery of `example` targets.\n\nDisabling automatic discovery should only be needed for specialized\nsituations. For example, if you have a library where you want a *module* named\n`bin`, this would present a problem because Cargo would usually attempt to\ncompile anything in the `bin` directory as an executable. Here is a sample\nlayout of this scenario:\n\n```\n\u251c\u2500\u2500 Cargo.toml\n\u2514\u2500\u2500 src\n    \u251c\u2500\u2500 lib.rs\n    \u2514\u2500\u2500 bin\n        \u2514\u2500\u2500 mod.rs\n```\n","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery"}}},"autotests":{"description":"Disable automatic discovery of `test` targets.\n\nDisabling automatic discovery should only be needed for specialized\nsituations. For example, if you have a library where you want a *module* named\n`bin`, this would present a problem because Cargo would usually attempt to\ncompile anything in the `bin` directory as an executable. Here is a sample\nlayout of this scenario:\n\n```\n\u251c\u2500\u2500 Cargo.toml\n\u2514\u2500\u2500 src\n    \u251c\u2500\u2500 lib.rs\n    \u2514\u2500\u2500 bin\n        \u2514\u2500\u2500 mod.rs\n```\n","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery"}}},"autobenches":{"description":"Disable automatic discovery of `bench` targets.\n\nDisabling automatic discovery should only be needed for specialized\nsituations. For example, if you have a library where you want a *module* named\n`bin`, this would present a problem because Cargo would usually attempt to\ncompile anything in the `bin` directory as an executable. Here is a sample\nlayout of this scenario:\n\n```\n\u251c\u2500\u2500 Cargo.toml\n\u2514\u2500\u2500 src\n    \u251c\u2500\u2500 lib.rs\n    \u2514\u2500\u2500 bin\n        \u2514\u2500\u2500 mod.rs\n```\n","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery"}}},"resolver":{"$ref":"#/definitions/Resolver"},"im-a-teapot":{"description":"Sets whether the current package is a teapot or something else that is not capable of brewing tea.","type":"boolean","x-taplo":{"hidden":true}},"metabuild":{"$ref":"#/definitions/MetaBuild","x-taplo":{"hidden":true}},"namespaced-features":{"type":"boolean","x-taplo":{"hidden":true}},"publish-lockfile":{"type":"boolean","x-taplo":{"hidden":true}}},"additionalProperties":false,"x-tombi-table-keys-order":"schema","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-package-section"}}},"Panic":{"title":"Panic","description":"The `panic` setting controls the [`-C panic` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#panic) which controls which panic\nstrategy to use.\n\nWhen set to `\"unwind\"`, the actual value depends on the default of the target\nplatform. For example, the NVPTX platform does not support unwinding, so it\nalways uses `\"abort\"`.\n\nTests, benchmarks, build scripts, and proc macros ignore the `panic` setting.\nThe `rustc` test harness currently requires `unwind` behavior. See the\n[`panic-abort-tests`](https://doc.rust-lang.org/cargo/reference/unstable.html#panic-abort-tests) unstable flag which enables `abort` behavior.\n\nAdditionally, when using the `abort` strategy and building a test, all of the\ndependencies will also be forced to built with the `unwind` strategy.","type":"string","enum":["unwind","abort"],"x-taplo":{"docs":{"enumValues":["Unwind the stack upon panic.","Terminate the process upon panic."]},"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#panic"}}},"Platform":{"title":"Platform","type":"object","properties":{"dependencies":{"description":"Cargo is configured to look for dependencies on [crates.io](https://crates.io) by default. Only\nthe name and a version string are required in this case. In [the cargo\nguide](https://doc.rust-lang.org/cargo/guide/index.html), we specified a dependency on the `time` crate:\n\n```toml\n[dependencies]\ntime = \"0.1.12\"\n```\n\nThe string `\"0.1.12\"` is a [semver](https://github.com/steveklabnik/semver#requirements) version requirement. Since this\nstring does not have any operators in it, it is interpreted the same way as\nif we had specified `\"^0.1.12\"`, which is called a caret requirement.\n\nA dependency can also be defined by a table with additional options:\n\n```toml\n[dependencies]\ntime = { path = \"../time\", version = \"0.1.12\" }\n```","type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html"}}},"dev-dependencies":{"description":"The format of `[dev-dependencies]` is equivalent to `[dependencies]`:\n\n```toml\n[dev-dependencies]\ntempdir = \"0.3\"\n```\n\nDev-dependencies are not used when compiling\na package for building, but are used for compiling tests, examples, and\nbenchmarks.\n\nThese dependencies are *not* propagated to other packages which depend on this\npackage.\n\nYou can also have target-specific development dependencies by using\n`dev-dependencies` in the target section header instead of `dependencies`. For\nexample:\n\n```toml\n[target.'cfg(unix)'.dev-dependencies]\nmio = \"0.0.1\"\n```\n\n> **Note**: When a package is published, only dev-dependencies that specify a\n> `version` will be included in the published crate. For most use cases,\n> dev-dependencies are not needed when published, though some users (like OS\n> packagers) may want to run tests within a crate, so providing a `version` if\n> possible can still be beneficial.\n","type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies"},"plugins":["crates"],"crates":{"schemas":"dependencies"}}},"dev_dependencies":{"type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"hidden":true}},"build-dependencies":{"description":"You can depend on other Cargo-based crates for use in your build scripts.\nDependencies are declared through the `build-dependencies` section of the\nmanifest:\n\n```toml\n[build-dependencies]\ncc = \"1.0.3\"\n```\n\nThe build script **does not** have access to the dependencies listed\nin the `dependencies` or `dev-dependencies` section. Build\ndependencies will likewise not be available to the package itself\nunless listed under the `dependencies` section as well. A package\nitself and its build script are built separately, so their\ndependencies need not coincide. Cargo is kept simpler and cleaner by\nusing independent dependencies for independent purposes.","type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#build-dependencies"},"plugins":["crates"],"crates":{"schemas":"dependencies"}}},"build_dependencies":{"type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"hidden":true}}},"x-tombi-table-keys-order":"schema"},"BuildOverride":{"title":"Build Override","description":"Profile settings can be overridden for specific packages and build-time\ncrates. To override the settings for a specific package, use the `package`\ntable to change the settings for the named package:\n\n```toml\n# The `foo` package will use the -Copt-level=3 flag.\n[profile.dev.package.foo]\nopt-level = 3\n```\n\nThe package name is actually a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can\ntarget individual versions of a package with syntax such as\n`[profile.dev.package.\"foo:2.1.0\"]`.\n\nTo override the settings for all dependencies (but not any workspace member),\nuse the `\"*\"` package name:\n\n```toml\n# Set the default for dependencies.\n[profile.dev.package.\"*\"]\nopt-level = 2\n```\n\nTo override the settings for build scripts, proc macros, and their\ndependencies, use the `build-override` table:\n\n```toml\n# Set the settings for build scripts and proc-macros.\n[profile.dev.build-override]\nopt-level = 3\n```\n\n> Note: When a dependency is both a normal dependency and a build dependency,\n> Cargo will try to only build it once when `--target` is not specified. When\n> using `build-override`, the dependency may need to be built twice, once as a\n> normal dependency and once with the overridden build settings. This may\n> increase initial build times.\n","allOf":[{"$ref":"#/definitions/Profile"}],"x-taplo":{"docs":{"main":"Profile settings can be overridden for specific packages and build-time\ncrates. To override the settings for a specific package, use the `package`\ntable to change the settings for the named package:\n\n```toml\n# The `foo` package will use the -Copt-level=3 flag.\n[profile.dev.package.foo]\nopt-level = 3\n```\n\nThe package name is actually a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can\ntarget individual versions of a package with syntax such as\n`[profile.dev.package.\"foo:2.1.0\"]`.\n\nTo override the settings for all dependencies (but not any workspace member),\nuse the `\"*\"` package name:\n\n```toml\n# Set the default for dependencies.\n[profile.dev.package.\"*\"]\nopt-level = 2\n```\n\nTo override the settings for build scripts, proc macros, and their\ndependencies, use the `build-override` table:\n\n```toml\n# Set the settings for build scripts and proc-macros.\n[profile.dev.build-override]\nopt-level = 3\n```\n\n> Note: When a dependency is both a normal dependency and a build dependency,\n> Cargo will try to only build it once when `--target` is not specified. When\n> using `build-override`, the dependency may need to be built twice, once as a\n> normal dependency and once with the overridden build settings. This may\n> increase initial build times.\n"},"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#overrides"}}},"ProfileWithBuildOverride":{"title":"Profile with Build Override","type":"object","properties":{"inherits":{"$ref":"#/definitions/Inherits"},"opt-level":{"$ref":"#/definitions/OptLevel"},"debug":{"$ref":"#/definitions/DebugLevel"},"split-debuginfo":{"$ref":"#/definitions/SplitDebuginfo"},"strip":{"$ref":"#/definitions/Strip"},"debug-assertions":{"$ref":"#/definitions/DebugAssertions"},"overflow-checks":{"$ref":"#/definitions/OverflowChecks"},"lto":{"$ref":"#/definitions/Lto"},"panic":{"$ref":"#/definitions/Panic"},"incremental":{"$ref":"#/definitions/Incremental"},"codegen-units":{"$ref":"#/definitions/CodegenUnits"},"rpath":{"$ref":"#/definitions/Rpath"},"package":{"$ref":"#/definitions/ProfilePackageOverrides"},"build-override":{"$ref":"#/definitions/Profile"}},"x-tombi-table-keys-order":"schema"},"SplitDebuginfo":{"title":"SplitDebuginfo","description":"The split-debuginfo setting controls the -C split-debuginfo flag which controls whether debug information, if generated, is either placed in the executable itself or adjacent to it. This can be useful for reducing the size of the executable, but may make it harder to debug the executable.","oneOf":[{"type":"string","enum":["off"],"description":"This is the default for platforms with ELF binaries and windows-gnu (not Windows MSVC and not macOS). This typically means that DWARF debug information can be found in the final artifact in sections of the executable. This option is not supported on Windows MSVC. On macOS this options prevents the final execution of dsymutil to generate debuginfo."},{"type":"string","enum":["packed"],"description":"This is the default for Windows MSVC and macOS. The term \"packed\" here means that all the debug information is packed into a separate file from the main executable. On Windows MSVC this is a *.pdb file, on macOS this is a *.dSYM folder, and on other platforms this is a *.dwp file."},{"type":"string","enum":["unpacked"],"description":"This means that debug information will be found in separate files for each compilation unit (object file). This is not supported on Windows MSVC. On macOS this means the original object files will contain debug information. On other Unix platforms this means that *.dwo files will contain debug information."}],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#split-debuginfo"}}},"Strip":{"oneOf":[{"type":"string","description":"The strip option controls the -C strip flag, which directs rustc to strip either symbols or debuginfo from a binary.","enum":["none","debuginfo","symbols"],"default":"none"},{"type":"boolean","enum":[true],"title":"Equivalent to \"symbols\"","description":"The strip option controls the -C strip flag, which directs rustc to strip either symbols or debuginfo from a binary."},{"type":"boolean","enum":[false],"title":"Equivalent to \"none\"","description":"The strip option controls the -C strip flag, which directs rustc to strip either symbols or debuginfo from a binary."}],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#strip"}}},"DebugAssertions":{"description":"The `debug-assertions` setting controls the [`-C debug-assertions` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#debug-assertions) which\nturns `cfg(debug_assertions)` [conditional compilation](https://doc.rust-lang.org/reference/conditional-compilation.html#debug_assertions) on or off. Debug\nassertions are intended to include runtime validation which is only available\nin debug/development builds. These may be things that are too expensive or\notherwise undesirable in a release build. Debug assertions enables the\n[`debug_assert!` macro](https://doc.rust-lang.org/std/macro.debug_assert.html) in the standard library.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#debug-assertions"}}},"OverflowChecks":{"description":"The `overflow-checks` setting controls the [`-C overflow-checks` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks) which\ncontrols the behavior of [runtime integer overflow](https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow). When overflow-checks are\nenabled, a panic will occur on overflow.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#overflow-checks"}}},"Incremental":{"description":"The `incremental` setting controls the [`-C incremental` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#incremental) which controls\nwhether or not incremental compilation is enabled. Incremental compilation\ncauses `rustc` to to save additional information to disk which will be reused\nwhen recompiling the crate, improving re-compile times. The additional\ninformation is stored in the `target` directory.\n\nThe valid options are:\n\n* `true`: enabled\n* `false`: disabled\n\nIncremental compilation is only used for workspace members and \"path\"\ndependencies.\n\nThe incremental value can be overridden globally with the `CARGO_INCREMENTAL`\n[environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html) or the [`build.incremental`](https://doc.rust-lang.org/cargo/reference/config.html#buildincremental) config variable.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#incremental"}}},"CodegenUnits":{"description":"The `codegen-units` setting controls the [`-C codegen-units` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units) which\ncontrols how many \"code generation units\" a crate will be split into. More\ncode generation units allows more of a crate to be processed in parallel\npossibly reducing compile time, but may produce slower code.\n\nThis option takes an integer greater than 0.\n\nThe default is 256 for [incremental](https://doc.rust-lang.org/cargo/reference/profiles.html#incremental) builds, and 16 for\nnon-incremental builds.","type":"integer","format":"uint32","minimum":0,"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units"}}},"Rpath":{"description":"The `rpath` setting controls the [`-C rpath` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#rpath) which controls\nwhether or not [`rpath`](https://en.wikipedia.org/wiki/Rpath) is enabled.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#rpath"}}},"ProfilePackageOverrides":{"description":"Package-specific overrides.\n\nThe package name is a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can\ntarget individual versions of a package with syntax such as `[profile.dev.package.\"foo:2.1.0\"]`.","type":"object","additionalProperties":{"$ref":"#/definitions/Profile"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html#overrides"}}},"Profile":{"title":"Profile","type":"object","properties":{"inherits":{"$ref":"#/definitions/Inherits"},"opt-level":{"$ref":"#/definitions/OptLevel"},"debug":{"$ref":"#/definitions/DebugLevel"},"split-debuginfo":{"$ref":"#/definitions/SplitDebuginfo"},"strip":{"$ref":"#/definitions/Strip"},"debug-assertions":{"$ref":"#/definitions/DebugAssertions"},"overflow-checks":{"$ref":"#/definitions/OverflowChecks"},"lto":{"$ref":"#/definitions/Lto"},"panic":{"$ref":"#/definitions/Panic"},"incremental":{"$ref":"#/definitions/Incremental"},"codegen-units":{"$ref":"#/definitions/CodegenUnits"},"rpath":{"$ref":"#/definitions/Rpath"},"package":{"$ref":"#/definitions/ProfilePackageOverrides"},"dir-name":{"type":"string","x-taplo":{"hidden":true}}},"x-tombi-table-keys-order":"schema"},"Profiles":{"title":"Profiles","description":"Profiles provide a way to alter the compiler settings, influencing things like optimizations and debugging symbols.\n\nCargo has 4 built-in profiles: dev, release, test, and bench. It automatically chooses the profile based on which command is being run, the package and target that is being built, and command-line flags like --release.","type":"object","properties":{"bench":{"$ref":"#/definitions/ProfileWithBuildOverride"},"dev":{"$ref":"#/definitions/ProfileWithBuildOverride"},"release":{"$ref":"#/definitions/ProfileWithBuildOverride"},"test":{"$ref":"#/definitions/ProfileWithBuildOverride"}},"additionalProperties":{"$ref":"#/definitions/ProfileWithBuildOverride"},"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/profiles.html"}}},"Publish":{"title":"Publish","description":"The `publish` field can be used to prevent a package from being published to a package registry (like *crates.io*) by mistake, for instance to keep a package\nprivate in a company.\n\n```toml\n[package]\n# ...\npublish = false\n```\n\nThe value may also be an array of strings which are registry names that are\nallowed to be published to.\n\n```toml\n[package]\n# ...\npublish = [\"some-registry-name\"]\n```","anyOf":[{"description":"A boolean indicating whether the package can be published.","type":"boolean","enum":[true,false],"default":true,"x-taplo":{"docs":{"enumValues":["The package can be published.","The package cannot be published."]}}},{"type":"array","description":"An array of registry names.","items":{"type":"string"},"x-tombi-array-values-order":"version-sort"}],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-publish-field"}}},"Readme":{"title":"Readme","description":"The `readme` field should be the path to a file in the package root (relative\nto this `Cargo.toml`) that contains general information about the package.\nThis file will be transferred to the registry when you publish. [crates.io](https://crates.io)\nwill interpret it as Markdown and render it on the crate's page.\n\n```toml\n[package]\n# ...\nreadme = \"README.md\"\n```\n\nIf no value is specified for this field, and a file named `README.md`,\n`README.txt` or `README` exists in the package root, then the name of that\nfile will be used. You can suppress this behavior by setting this field to\n`false`. If the field is set to `true`, a default value of `README.md` will\nbe assumed.\n","anyOf":[{"description":"The `readme` field should be the path to a file in the package root (relative\nto this `Cargo.toml`) that contains general information about the package.","type":"string"},{"type":"boolean","enum":[true,false],"x-taplo":{"docs":{"enumValues":["Use the `README.md` file.","Do not use the default `README.md` file"]}}}],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-readme-field"}}},"SemVer":{"title":"Semantic Version","description":"Cargo bakes in the concept of [Semantic Versioning](https://semver.org/), so make sure you follow some basic rules:\n\n* Before you reach 1.0.0, anything goes, but if you make breaking changes,\n    increment the minor version. In Rust, breaking changes include adding fields to\n    structs or variants to enums.\n* After 1.0.0, only make breaking changes when you increment the major version.\n    Don't break the build.\n* After 1.0.0, don't add any new public API (no new `pub` anything) in patch-level\n    versions. Always increment the minor version if you add any new `pub` structs,\n    traits, fields, types, functions, methods or anything else.\n* Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.","default":"0.1.0","type":"string","format":"semver","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field"}}},"SemVerRequirement":{"title":"Semantic Version Requirement","description":"The [version requirement](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) of the target dependency.","default":"*","type":"string","format":"semver-requirement","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html"},"plugins":["crates"],"crates":{"schemas":"version"}}},"Target":{"title":"Target","type":"object","properties":{"bench":{"description":"The `bench` field indicates whether or not the target is benchmarked by\ndefault by [`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html). The default is `true` for lib, bins, and\nbenchmarks.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-bench-field"}}},"crate-type":{"description":"The `crate-type` field defines the [crate types](https://doc.rust-lang.org/reference/linkage.html) that will be generated by the\ntarget. It is an array of strings, allowing you to specify multiple crate\ntypes for a single target. This can only be specified for libraries and\nexamples. Binaries, tests, and benchmarks are always the \"bin\" crate type.\n\nThe available options are `bin`, `lib`, `rlib`, `dylib`, `cdylib`,\n`staticlib`, and `proc-macro`. You can read more about the different crate\ntypes in the [Rust Reference Manual](https://doc.rust-lang.org/reference/linkage.html).","type":"array","items":{"description":"The `crate-type` field defines the [crate types](https://doc.rust-lang.org/reference/linkage.html) that will be generated by the\ntarget. It is an array of strings, allowing you to specify multiple crate\ntypes for a single target. This can only be specified for libraries and\nexamples. Binaries, tests, and benchmarks are always the \"bin\" crate type.\n\nThe available options are `bin`, `lib`, `rlib`, `dylib`, `cdylib`,\n`staticlib`, and `proc-macro`. You can read more about the different crate\ntypes in the [Rust Reference Manual](https://doc.rust-lang.org/reference/linkage.html).","type":"string","x-taplo":{"docs":{"enumValues":["A runnable executable will be produced. This requires that there is a `main` function in the crate which\nwill be run when the program begins executing. This will link in all Rust and\nnative dependencies, producing a distributable binary.","A Rust library will be produced.\nThis is an ambiguous concept as to what exactly is produced because a library\ncan manifest itself in several forms. The purpose of this generic `lib` option\nis to generate the \"compiler recommended\" style of library. The output library\nwill always be usable by rustc, but the actual type of library may change from\ntime-to-time. The remaining output types are all different flavors of\nlibraries, and the `lib` type can be seen as an alias for one of them (but the\nactual one is compiler-defined).","A \"Rust library\" file will be produced. This is used as an intermediate artifact and can be thought of as a\n\"static Rust library\". These `rlib` files, unlike `staticlib` files, are\ninterpreted by the compiler in future linkage. This essentially means\nthat `rustc` will look for metadata in `rlib` files like it looks for metadata\nin dynamic libraries. This form of output is used to produce statically linked\nexecutables as well as `staticlib` outputs.","A dynamic Rust library will be produced. This is different from the `lib` output type in that this forces\ndynamic library generation. The resulting dynamic library can be used as a\ndependency for other libraries and/or executables. This output type will\ncreate `*.so` files on linux, `*.dylib` files on osx, and `*.dll` files on\nwindows.","A dynamic system library will be produced. This is used when compiling\na dynamic library to be loaded from another language.  This output type will\ncreate `*.so` files on Linux, `*.dylib` files on macOS, and `*.dll` files on\nWindows.","A static system library will be produced. This is different from other library outputs in that\nthe compiler will never attempt to link to `staticlib` outputs. The\npurpose of this output type is to create a static library containing all of\nthe local crate's code along with all upstream dependencies. The static\nlibrary is actually a `*.a` archive on linux and osx and a `*.lib` file on\nwindows. This format is recommended for use in situations such as linking\nRust code into an existing non-Rust application because it will not have\ndynamic dependencies on other Rust code.","The output produced is not specified, but if a `-L` path is provided to it then the\ncompiler will recognize the output artifacts as a macro and it can be loaded\nfor a program. Crates compiled with this crate type  must only export\n[procedural macros](https://doc.rust-lang.org/reference/procedural-macros.html). The compiler will automatically set the `proc_macro`\n[configuration option](https://doc.rust-lang.org/reference/conditional-compilation.html). The crates are always compiled with the same target\nthat the compiler itself was built with. For example, if you are executing\nthe compiler from Linux with an `x86_64` CPU, the target will be\n`x86_64-unknown-linux-gnu` even if the crate is a dependency of another crate\nbeing built for a different target."]},"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-crate-type-field"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"docs":{"enumValues":["A runnable executable will be produced. This requires that there is a `main` function in the crate which\nwill be run when the program begins executing. This will link in all Rust and\nnative dependencies, producing a distributable binary.","A Rust library will be produced.\nThis is an ambiguous concept as to what exactly is produced because a library\ncan manifest itself in several forms. The purpose of this generic `lib` option\nis to generate the \"compiler recommended\" style of library. The output library\nwill always be usable by rustc, but the actual type of library may change from\ntime-to-time. The remaining output types are all different flavors of\nlibraries, and the `lib` type can be seen as an alias for one of them (but the\nactual one is compiler-defined).","A \"Rust library\" file will be produced. This is used as an intermediate artifact and can be thought of as a\n\"static Rust library\". These `rlib` files, unlike `staticlib` files, are\ninterpreted by the compiler in future linkage. This essentially means\nthat `rustc` will look for metadata in `rlib` files like it looks for metadata\nin dynamic libraries. This form of output is used to produce statically linked\nexecutables as well as `staticlib` outputs.","A dynamic Rust library will be produced. This is different from the `lib` output type in that this forces\ndynamic library generation. The resulting dynamic library can be used as a\ndependency for other libraries and/or executables. This output type will\ncreate `*.so` files on linux, `*.dylib` files on osx, and `*.dll` files on\nwindows.","A dynamic system library will be produced. This is used when compiling\na dynamic library to be loaded from another language.  This output type will\ncreate `*.so` files on Linux, `*.dylib` files on macOS, and `*.dll` files on\nWindows.","A static system library will be produced. This is different from other library outputs in that\nthe compiler will never attempt to link to `staticlib` outputs. The\npurpose of this output type is to create a static library containing all of\nthe local crate's code along with all upstream dependencies. The static\nlibrary is actually a `*.a` archive on linux and osx and a `*.lib` file on\nwindows. This format is recommended for use in situations such as linking\nRust code into an existing non-Rust application because it will not have\ndynamic dependencies on other Rust code.","The output produced is not specified, but if a `-L` path is provided to it then the\ncompiler will recognize the output artifacts as a macro and it can be loaded\nfor a program. Crates compiled with this crate type  must only export\n[procedural macros](https://doc.rust-lang.org/reference/procedural-macros.html). The compiler will automatically set the `proc_macro`\n[configuration option](https://doc.rust-lang.org/reference/conditional-compilation.html). The crates are always compiled with the same target\nthat the compiler itself was built with. For example, if you are executing\nthe compiler from Linux with an `x86_64` CPU, the target will be\n`x86_64-unknown-linux-gnu` even if the crate is a dependency of another crate\nbeing built for a different target."]},"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-crate-type-field"}}},"crate_type":{"type":"array","items":{"type":"string","x-taplo":{"hidden":true}},"x-tombi-array-values-order":"version-sort","x-taplo":{"hidden":true}},"doc":{"description":"The `doc` field indicates whether or not the target is included in the\ndocumentation generated by [`cargo doc`](https://doc.rust-lang.org/cargo/commands/cargo-doc.html) by default. The default is `true` for\nlibraries and binaries.\n\n> **Note**: The binary will be skipped if its name is the same as the lib\n> target.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-doc-field"}}},"doctest":{"description":"The `doctest` field indicates whether or not [documentation examples](https://doc.rust-lang.org/rustdoc/documentation-tests.html) are\ntested by default by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html). This is only relevant for libraries, it\nhas no effect on other sections. The default is `true` for the library.\n","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-doctest-field"}}},"edition":{"$ref":"#/definitions/Edition"},"harness":{"description":"The `harness` field indicates that the [`--test` flag](https://doc.rust-lang.org/rustc/command-line-arguments.html#option-test) will be passed to\n`rustc` which will automatically include the libtest library which is the\ndriver for collecting and running tests marked with the [`#[test]` attribute](https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute) or benchmarks with the `#[bench]` attribute. The\ndefault is `true` for all targets.\n\nIf set to `false`, then you are responsible for defining a `main()` function\nto run tests and benchmarks.\n\nTests have the [`cfg(test)` conditional expression](https://doc.rust-lang.org/reference/conditional-compilation.html#test) enabled whether\nor not the harness is enabled.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-harness-field"}}},"name":{"description":"The `name` field specifies the name of the target, which corresponds to the\nfilename of the artifact that will be generated. For a library, this is the\ncrate name that dependencies will use to reference it.\n\nFor the `[lib]` and the default binary (`src/main.rs`), this defaults to the\nname of the package, with any dashes replaced with underscores. For other\n[auto discovered](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery) targets, it defaults to the\ndirectory or file name.\n\nThis is required for all targets except `[lib]`.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-name-field"}}},"path":{"description":"The `path` field specifies where the source for the crate is located, relative\nto the `Cargo.toml` file.\n\nIf not specified, the [inferred path](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery) is used based on\nthe target name.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-path-field"}}},"plugin":{"type":"boolean","x-taplo":{"hidden":true}},"proc-macro":{"description":"The `proc-macro` field indicates that the library is a [procedural macro](https://doc.rust-lang.org/book/ch19-06-macros.html)\n([reference](https://doc.rust-lang.org/reference/procedural-macros.html)). This is only valid for the `[lib]`\ntarget.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-proc-macro-field"}}},"proc_macro":{"type":"boolean","x-taplo":{"hidden":true}},"required-features":{"description":"The `required-features` field specifies which [features](https://doc.rust-lang.org/cargo/reference/features.html) the target needs in\norder to be built. If any of the required features are not enabled, the\ntarget will be skipped. This is only relevant for the `[[bin]]`, `[[bench]]`,\n`[[test]]`, and `[[example]]` sections, it has no effect on `[lib]`.\n\n```toml\n[features]\n# ...\npostgres = []\nsqlite = []\ntools = []\n\n[[bin]]\nname = \"my-pg-tool\"\nrequired-features = [\"postgres\", \"tools\"]\n```\n","type":"array","items":{"description":"The `required-features` field specifies which [features](https://doc.rust-lang.org/cargo/reference/features.html) the target needs in\norder to be built. If any of the required features are not enabled, the\ntarget will be skipped. This is only relevant for the `[[bin]]`, `[[bench]]`,\n`[[test]]`, and `[[example]]` sections, it has no effect on `[lib]`.\n\n```toml\n[features]\n# ...\npostgres = []\nsqlite = []\ntools = []\n\n[[bin]]\nname = \"my-pg-tool\"\nrequired-features = [\"postgres\", \"tools\"]\n```\n","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-required-features-field"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-required-features-field"}}},"test":{"description":"The `test` field indicates whether or not the target is tested by default by\n[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html). The default is `true` for lib, bins, and tests.\n\n> **Note**: Examples are built by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by default to ensure they\n> continue to compile, but they are not *tested* by default. Setting `test =\n> true` for an example will also build it as a test and run any\n> [`#[test]`](https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute) functions defined in the example.","type":"boolean","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-test-field"}}}},"x-tombi-table-keys-order":"schema"},"Workspace":{"title":"Workspace","description":"The `[workspace]` table in `Cargo.toml` defines which packages are members of\nthe workspace:\n\n```toml\n[workspace]\nmembers = [\"member1\", \"path/to/member2\", \"crates/*\"]\nexclude = [\"crates/foo\", \"path/to/other\"]\n```\n\nAn empty `[workspace]` table can be used with a `[package]` to conveniently\ncreate a workspace with the package and all of its path dependencies.\n\nAll [`path` dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies) residing in the workspace directory automatically\nbecome members. Additional members can be listed with the `members` key, which\nshould be an array of strings containing directories with `Cargo.toml` files.\n\nThe `members` list also supports [globs](https://docs.rs/glob/0.3.0/glob/struct.Pattern.html) to match multiple paths, using\ntypical filename glob patterns like `*` and `?`.\n\nThe `exclude` key can be used to prevent paths from being included in a\nworkspace. This can be useful if some path dependencies aren't desired to be\nin the workspace at all, or using a glob pattern and you want to remove a\ndirectory.\n\nAn empty `[workspace]` table can be used with a `[package]` to conveniently\ncreate a workspace with the package and all of its path dependencies.","type":"object","properties":{"resolver":{"$ref":"#/definitions/Resolver"},"members":{"description":"All [`path` dependencies] residing in the workspace directory automatically\nbecome members. Additional members can be listed with the `members` key, which\nshould be an array of strings containing directories with `Cargo.toml` files.\n\nThe `members` list also supports [globs] to match multiple paths, using\ntypical filename glob patterns like `*` and `?`.","type":"array","items":{"description":"All [`path` dependencies] residing in the workspace directory automatically\nbecome members. Additional members can be listed with the `members` key, which\nshould be an array of strings containing directories with `Cargo.toml` files.\n\nThe `members` list also supports [globs] to match multiple paths, using\ntypical filename glob patterns like `*` and `?`.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}},"exclude":{"description":"The `exclude` key can be used to prevent paths from being included in a\nworkspace. This can be useful if some path dependencies aren't desired to be\nin the workspace at all, or using a glob pattern and you want to remove a\ndirectory.","type":"array","items":{"description":"The `exclude` key can be used to prevent paths from being included in a\nworkspace. This can be useful if some path dependencies aren't desired to be\nin the workspace at all, or using a glob pattern and you want to remove a\ndirectory.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}},"default-members":{"description":"The optional `default-members` key can be specified to set the members to\noperate on when in the workspace root and the package selection flags are not\nused:\n\n```toml\n[workspace]\nmembers = [\"path/to/member1\", \"path/to/member2\", \"path/to/member3/*\"]\ndefault-members = [\"path/to/member2\", \"path/to/member3/foo\"]\n```\n\nWhen specified, `default-members` must expand to a subset of `members`.","type":"array","items":{"description":"The optional `default-members` key can be specified to set the members to\noperate on when in the workspace root and the package selection flags are not\nused:\n\n```toml\n[workspace]\nmembers = [\"path/to/member1\", \"path/to/member2\", \"path/to/member3/*\"]\ndefault-members = [\"path/to/member2\", \"path/to/member3/foo\"]\n```\n\nWhen specified, `default-members` must expand to a subset of `members`.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}},"package":{"description":"The `workspace.package` table is where you define keys that can be\ninherited by members of a workspace. These keys can be inherited by\ndefining them in the member package with `{key}.workspace = true`.\n\nKeys that are supported:\n\n|                |                 |\n|----------------|-----------------|\n| `authors`      | `categories`    |\n| `description`  | `documentation` |\n| `edition`      | `exclude`       |\n| `homepage`     | `include`       |\n| `keywords`     | `license`       |\n| `license-file` | `publish`       |\n| `readme`       | `repository`    |\n| `rust-version` | `version`       |\n\n- `license-file` and `readme` are relative to the workspace root\n- `include` and `exclude` are relative to your package root\n\nExample:\n```toml\n# [PROJECT_DIR]/Cargo.toml\n[workspace]\nmembers = [\"bar\"]\n\n[workspace.package]\nversion = \"1.2.3\"\nauthors = [\"Nice Folks\"]\ndescription = \"A short description of my package\"\ndocumentation = \"https://example.com/bar\"\n```\n\n```toml\n# [PROJECT_DIR]/bar/Cargo.toml\n[package]\nname = \"bar\"\nversion.workspace = true\nauthors.workspace = true\ndescription.workspace = true\ndocumentation.workspace = true\n```","type":"object","properties":{"version":{"$ref":"#/definitions/SemVer"},"authors":{"$ref":"#/definitions/Authors"},"edition":{"$ref":"#/definitions/Edition"},"rust-version":{"$ref":"#/definitions/RustVersion"},"description":{"$ref":"#/definitions/Description"},"documentation":{"$ref":"#/definitions/Documentation"},"readme":{"$ref":"#/definitions/Readme"},"homepage":{"$ref":"#/definitions/Homepage"},"repository":{"$ref":"#/definitions/Repository"},"license":{"$ref":"#/definitions/License"},"license-file":{"$ref":"#/definitions/LicenseFile"},"keywords":{"$ref":"#/definitions/Keywords"},"categories":{"$ref":"#/definitions/Categories"},"exclude":{"$ref":"#/definitions/Exclude"},"include":{"$ref":"#/definitions/Include"},"publish":{"$ref":"#/definitions/Publish"}},"x-tombi-table-keys-order":"schema","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-package-table"}}},"dependencies":{"description":"The `workspace.dependencies` table is where you define dependencies to be\ninherited by members of a workspace.\n\nSpecifying a workspace dependency is similar to [package dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) except:\n- Dependencies from this table cannot be declared as `optional`\n- [`features`][features] declared in this table are additive with the `features` from `[dependencies]`\n\nYou can then [inherit the workspace dependency as a package dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace)\n\nExample:\n```toml\n# [PROJECT_DIR]/Cargo.toml\n[workspace]\nmembers = [\"bar\"]\n\n[workspace.dependencies]\ncc = \"1.0.73\"\nrand = \"0.8.5\"\nregex = { version = \"1.6.0\", default-features = false, features = [\"std\"] }\n```\n\n```toml\n# [PROJECT_DIR]/bar/Cargo.toml\n[package]\nname = \"bar\"\nversion = \"0.2.0\"\n\n[dependencies]\nregex = { workspace = true, features = [\"unicode\"] }\n\n[build-dependencies]\ncc.workspace = true\n\n[dev-dependencies]\nrand.workspace = true\n```","type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}},"lints":{"$ref":"#/definitions/Lints","description":"The `workspace.lints` table is where you define lint configuration to be inherited by members of a workspace.","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}},"metadata":{"description":"The `workspace.metadata` table is ignored by Cargo and will not be warned\nabout. This section can be used for tools that would like to store workspace\nconfiguration in `Cargo.toml`. For example:\n\n```toml\n[workspace]\nmembers = [\"member1\", \"member2\"]\n\n[workspace.metadata.webcontents]\nroot = \"path/to/webproject\"\ntool = [\"npm\", \"run\", \"build\"]\n# ...\n```\n\nThere is a similar set of tables at the package level at\n`package.metadata`. While cargo does not specify a\nformat for the content of either of these tables, it is suggested that\nexternal tools may wish to use them in a consistent fashion, such as referring\nto the data in `workspace.metadata` if data is missing from `package.metadata`,\nif that makes sense for the tool in question.\n","type":"object","additionalProperties":true,"x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html#the-workspace-section"}}}},"x-tombi-table-keys-order":"schema","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/workspaces.html"}}},"Authors":{"title":"Authors","description":"The `authors` field lists people or organizations that are considered the\n\"authors\" of the package. The exact meaning is open to interpretation \u2014 it may\nlist the original or primary authors, current maintainers, or owners of the\npackage. These names will be listed on the crate's page on\n[crates.io](https://crates.io). An optional email address may be included within angled\nbrackets at the end of each author.\n\n> **Note**: [crates.io](https://crates.io) requires at least one author to be listed.","type":"array","items":{"description":"The `authors` field lists people or organizations that are considered the\n\"authors\" of the package. The exact meaning is open to interpretation \u2014 it may\nlist the original or primary authors, current maintainers, or owners of the\npackage. These names will be listed on the crate's page on\n[crates.io](https://crates.io). An optional email address may be included within angled\nbrackets at the end of each author.\n\n> **Note**: [crates.io](https://crates.io) requires at least one author to be listed.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-authors-field"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-authors-field"}}},"Categories":{"title":"Categories","description":"The `categories` field is an array of strings of the categories this package\nbelongs to.\n\n```toml\ncategories = [\"command-line-utilities\", \"development-tools::cargo-plugins\"]\n```\n\n> **Note**: [crates.io](https://crates.io) has a maximum of 5 categories. Each category should\n> match one of the strings available at https://crates.io/category_slugs, and\n> must match exactly.","type":"array","items":{"description":"The `categories` field is an array of strings of the categories this package\nbelongs to.\n\n```toml\ncategories = [\"command-line-utilities\", \"development-tools::cargo-plugins\"]\n```\n\n> **Note**: [crates.io](https://crates.io) has a maximum of 5 categories. Each category should\n> match one of the strings available at https://crates.io/category_slugs, and\n> must match exactly.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-categories-field"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-categories-field"}}},"Description":{"title":"Description","description":"The description is a short blurb about the package. [crates.io](https://crates.io) will display\nthis with your package. This should be plain text (not Markdown).\n\n```toml\n[package]\n# ...\ndescription = \"A short description of my package\"\n```\n\n> **Note**: [crates.io](https://crates.io) requires the `description` to be set.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-description-field"}}},"Documentation":{"title":"Documentation","description":"\nThe `documentation` field specifies a URL to a website hosting the crate's\ndocumentation. If no URL is specified in the manifest file, [crates.io](https://crates.io) will\nautomatically link your crate to the corresponding [docs.rs](https://docs.rs) page.\n\n```toml\n[package]\n# ...\ndocumentation = \"https://docs.rs/bitflags\"\n```\n","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-documentation-field"}}},"Exclude":{"title":"Exclude","description":"You can explicitly specify that a set of file patterns should be ignored or\nincluded for the purposes of packaging. The patterns specified in the\n`exclude` field identify a set of files that are not included, and the\npatterns in `include` specify files that are explicitly included.\n\nThe patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:\n\n- `foo` matches any file or directory with the name `foo` anywhere in the\n  package. This is equivalent to the pattern `**/foo`.\n- `/foo` matches any file or directory with the name `foo` only in the root of\n  the package.\n- `foo/` matches any *directory* with the name `foo` anywhere in the package.\n- Common glob patterns like `*`, `?`, and `[]` are supported:\n  - `*` matches zero or more characters except `/`.  For example, `*.html`\n    matches any file or directory with the `.html` extension anywhere in the\n    package.\n  - `?` matches any character except `/`. For example, `foo?` matches `food`,\n    but not `foo`.\n  - `[]` allows for matching a range of characters. For example, `[ab]`\n    matches either `a` or `b`. `[a-z]` matches letters a through z.\n- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the\n  file or directory `bar` anywhere that is directly under directory `foo`.\n- `/**` suffix matches everything inside. For example, `foo/**` matches all\n  files inside directory `foo`, including all files in subdirectories below\n  `foo`.\n- `/**/` matches zero or more directories. For example, `a/**/b` matches\n  `a/b`, `a/x/b`, `a/x/y/b`, and so on.\n- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and\n  `!foo.rs` would match all files with the `.rs` extension inside the `src`\n  directory, except for any file named `foo.rs`.\n\nIf git is being used for a package, the `exclude` field will be seeded with\nthe `gitignore` settings from the repository.\n\n```toml\n[package]\n# ...\nexclude = [\"build/**/*.o\", \"doc/**/*.html\"]\n```\n\n```toml\n[package]\n# ...\ninclude = [\"src/**/*\", \"Cargo.toml\"]\n```\n\nThe options are mutually exclusive: setting `include` will override an\n`exclude`. Note that `include` must be an exhaustive list of files as otherwise\nnecessary source files may not be included. The package's `Cargo.toml` is\nautomatically included.\n\nThe include/exclude list is also used for change tracking in some situations.\nFor targets built with `rustdoc`, it is used to determine the list of files to\ntrack to determine if the target should be rebuilt. If the package has a\n[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the\ninclude/exclude list is used for tracking if the build script should be re-run\nif any of those files change.","type":"array","items":{"description":"You can explicitly specify that a set of file patterns should be ignored or\nincluded for the purposes of packaging. The patterns specified in the\n`exclude` field identify a set of files that are not included, and the\npatterns in `include` specify files that are explicitly included.\n\nThe patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:\n\n- `foo` matches any file or directory with the name `foo` anywhere in the\n  package. This is equivalent to the pattern `**/foo`.\n- `/foo` matches any file or directory with the name `foo` only in the root of\n  the package.\n- `foo/` matches any *directory* with the name `foo` anywhere in the package.\n- Common glob patterns like `*`, `?`, and `[]` are supported:\n  - `*` matches zero or more characters except `/`.  For example, `*.html`\n    matches any file or directory with the `.html` extension anywhere in the\n    package.\n  - `?` matches any character except `/`. For example, `foo?` matches `food`,\n    but not `foo`.\n  - `[]` allows for matching a range of characters. For example, `[ab]`\n    matches either `a` or `b`. `[a-z]` matches letters a through z.\n- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the\n  file or directory `bar` anywhere that is directly under directory `foo`.\n- `/**` suffix matches everything inside. For example, `foo/**` matches all\n  files inside directory `foo`, including all files in subdirectories below\n  `foo`.\n- `/**/` matches zero or more directories. For example, `a/**/b` matches\n  `a/b`, `a/x/b`, `a/x/y/b`, and so on.\n- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and\n  `!foo.rs` would match all files with the `.rs` extension inside the `src`\n  directory, except for any file named `foo.rs`.\n\nIf git is being used for a package, the `exclude` field will be seeded with\nthe `gitignore` settings from the repository.\n\n```toml\n[package]\n# ...\nexclude = [\"build/**/*.o\", \"doc/**/*.html\"]\n```\n\n```toml\n[package]\n# ...\ninclude = [\"src/**/*\", \"Cargo.toml\"]\n```\n\nThe options are mutually exclusive: setting `include` will override an\n`exclude`. Note that `include` must be an exhaustive list of files as otherwise\nnecessary source files may not be included. The package's `Cargo.toml` is\nautomatically included.\n\nThe include/exclude list is also used for change tracking in some situations.\nFor targets built with `rustdoc`, it is used to determine the list of files to\ntrack to determine if the target should be rebuilt. If the package has a\n[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the\ninclude/exclude list is used for tracking if the build script should be re-run\nif any of those files change.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields"}}},"Homepage":{"title":"Homepage","description":"The `homepage` field should be a URL to a site that is the home page for your\npackage.\n\n```toml\n[package]\n# ...\nhomepage = \"https://serde.rs/\"\n```","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-homepage-field"}}},"Include":{"description":"You can explicitly specify that a set of file patterns should be ignored or\nincluded for the purposes of packaging. The patterns specified in the\n`exclude` field identify a set of files that are not included, and the\npatterns in `include` specify files that are explicitly included.\n\nThe patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:\n\n- `foo` matches any file or directory with the name `foo` anywhere in the\n  package. This is equivalent to the pattern `**/foo`.\n- `/foo` matches any file or directory with the name `foo` only in the root of\n  the package.\n- `foo/` matches any *directory* with the name `foo` anywhere in the package.\n- Common glob patterns like `*`, `?`, and `[]` are supported:\n  - `*` matches zero or more characters except `/`.  For example, `*.html`\n    matches any file or directory with the `.html` extension anywhere in the\n    package.\n  - `?` matches any character except `/`. For example, `foo?` matches `food`,\n    but not `foo`.\n  - `[]` allows for matching a range of characters. For example, `[ab]`\n    matches either `a` or `b`. `[a-z]` matches letters a through z.\n- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the\n  file or directory `bar` anywhere that is directly under directory `foo`.\n- `/**` suffix matches everything inside. For example, `foo/**` matches all\n  files inside directory `foo`, including all files in subdirectories below\n  `foo`.\n- `/**/` matches zero or more directories. For example, `a/**/b` matches\n  `a/b`, `a/x/b`, `a/x/y/b`, and so on.\n- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and\n  `!foo.rs` would match all files with the `.rs` extension inside the `src`\n  directory, except for any file named `foo.rs`.\n\nIf git is being used for a package, the `exclude` field will be seeded with\nthe `gitignore` settings from the repository.\n\n```toml\n[package]\n# ...\nexclude = [\"build/**/*.o\", \"doc/**/*.html\"]\n```\n\n```toml\n[package]\n# ...\ninclude = [\"src/**/*\", \"Cargo.toml\"]\n```\n\nThe options are mutually exclusive: setting `include` will override an\n`exclude`. Note that `include` must be an exhaustive list of files as otherwise\nnecessary source files may not be included. The package's `Cargo.toml` is\nautomatically included.\n\nThe include/exclude list is also used for change tracking in some situations.\nFor targets built with `rustdoc`, it is used to determine the list of files to\ntrack to determine if the target should be rebuilt. If the package has a\n[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the\ninclude/exclude list is used for tracking if the build script should be re-run\nif any of those files change.","type":"array","items":{"description":"You can explicitly specify that a set of file patterns should be ignored or\nincluded for the purposes of packaging. The patterns specified in the\n`exclude` field identify a set of files that are not included, and the\npatterns in `include` specify files that are explicitly included.\n\nThe patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:\n\n- `foo` matches any file or directory with the name `foo` anywhere in the\n  package. This is equivalent to the pattern `**/foo`.\n- `/foo` matches any file or directory with the name `foo` only in the root of\n  the package.\n- `foo/` matches any *directory* with the name `foo` anywhere in the package.\n- Common glob patterns like `*`, `?`, and `[]` are supported:\n  - `*` matches zero or more characters except `/`.  For example, `*.html`\n    matches any file or directory with the `.html` extension anywhere in the\n    package.\n  - `?` matches any character except `/`. For example, `foo?` matches `food`,\n    but not `foo`.\n  - `[]` allows for matching a range of characters. For example, `[ab]`\n    matches either `a` or `b`. `[a-z]` matches letters a through z.\n- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the\n  file or directory `bar` anywhere that is directly under directory `foo`.\n- `/**` suffix matches everything inside. For example, `foo/**` matches all\n  files inside directory `foo`, including all files in subdirectories below\n  `foo`.\n- `/**/` matches zero or more directories. For example, `a/**/b` matches\n  `a/b`, `a/x/b`, `a/x/y/b`, and so on.\n- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and\n  `!foo.rs` would match all files with the `.rs` extension inside the `src`\n  directory, except for any file named `foo.rs`.\n\nIf git is being used for a package, the `exclude` field will be seeded with\nthe `gitignore` settings from the repository.\n\n```toml\n[package]\n# ...\nexclude = [\"build/**/*.o\", \"doc/**/*.html\"]\n```\n\n```toml\n[package]\n# ...\ninclude = [\"src/**/*\", \"Cargo.toml\"]\n```\n\nThe options are mutually exclusive: setting `include` will override an\n`exclude`. Note that `include` must be an exhaustive list of files as otherwise\nnecessary source files may not be included. The package's `Cargo.toml` is\nautomatically included.\n\nThe include/exclude list is also used for change tracking in some situations.\nFor targets built with `rustdoc`, it is used to determine the list of files to\ntrack to determine if the target should be rebuilt. If the package has a\n[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the\ninclude/exclude list is used for tracking if the build script should be re-run\nif any of those files change.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields"}}},"Keywords":{"title":"Keywords","description":"The `keywords` field is an array of strings that describe this package. This\ncan help when searching for the package on a registry, and you may choose any\nwords that would help someone find this crate.\n\n```toml\n[package]\n# ...\nkeywords = [\"gamedev\", \"graphics\"]\n```\n\n> **Note**: [crates.io](https://crates.io) has a maximum of 5 keywords. Each keyword must be\n> ASCII text, start with a letter, and only contain letters, numbers, `_` or\n> `-`, and have at most 20 characters.","type":"array","items":{"description":"The `keywords` field is an array of strings that describe this package. This\ncan help when searching for the package on a registry, and you may choose any\nwords that would help someone find this crate.\n\n```toml\n[package]\n# ...\nkeywords = [\"gamedev\", \"graphics\"]\n```\n\n> **Note**: [crates.io](https://crates.io) has a maximum of 5 keywords. Each keyword must be\n> ASCII text, start with a letter, and only contain letters, numbers, `_` or\n> `-`, and have at most 20 characters.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-keywords-field"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-keywords-field"}}},"License":{"title":"License","description":"The `license` field contains the name of the software license that the package\nis released under.\n\n[crates.io](https://crates.io/) interprets the `license` field as an [SPDX 2.1 license\nexpression](https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60). The name must be a known license\nfrom the [SPDX license list 3.6](https://github.com/spdx/license-list-data/tree/v3.6). Parentheses are not\ncurrently supported. See the [SPDX site](https://spdx.org/license-list) for more information.\n\nSPDX license expressions support AND and OR operators to combine multiple\nlicenses.\n\n```toml\n[package]\n# ...\nlicense = \"MIT OR Apache-2.0\"\n```\n\nUsing `OR` indicates the user may choose either license. Using `AND` indicates\nthe user must comply with both licenses simultaneously. The `WITH` operator\nindicates a license with a special exception. Some examples:\n\n* `MIT OR Apache-2.0`\n* `LGPL-2.1 AND MIT AND BSD-2-Clause`\n* `GPL-2.0+ WITH Bison-exception-2.2`\n\nIf a package is using a nonstandard license, then the `license-file` field may\nbe specified in lieu of the `license` field.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields"}}},"LicenseFile":{"title":"LicenseFile","description":"The `license-file` field contains the path to a file\ncontaining the text of the license (relative to this `Cargo.toml`).\n\n```toml\n[package]\n# ...\nlicense-file = \"LICENSE.txt\"\n```\n\n> **Note**: [crates.io](https://crates.io) requires either `license` or `license-file` to be set.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields"}}},"Repository":{"title":"Repository","description":"The `repository` field should be a URL to the source repository for your\npackage.\n\n```toml\n[package]\n# ...\nrepository = \"https://github.com/rust-lang/cargo/\"\n```","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-repository-field"}}},"RustVersion":{"title":"RustVersion","description":"The `rust-version` field is an optional key that tells cargo what version of the\nRust language and compiler your package can be compiled with. If the currently\nselected version of the Rust compiler is older than the stated version, cargo\nwill exit with an error, telling the user what version is required.\n\nThe first version of Cargo that supports this field was released with Rust 1.56.0.\nIn older releases, the field will be ignored, and Cargo will display a warning.\n\n```toml\n[package]\n# ...\nrust-version = \"1.56\"\n```\n\nThe Rust version must be a bare version number with two or three components; it\ncannot include semver operators or pre-release identifiers. Compiler pre-release\nidentifiers such as -nightly will be ignored while checking the Rust version.\nThe `rust-version` must be equal to or newer than the version that first\nintroduced the configured `edition`.\n\nThe `rust-version` may be ignored using the `--ignore-rust-version` option.\n\nSetting the `rust-version` key in `[package]` will affect all targets/crates in\nthe package, including test suites, benchmarks, binaries, examples, etc.","type":"string","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field"}}},"WorkspaceInheritance":{"type":"object","properties":{"workspace":{"title":"Workspace","description":"The `workspace` field allow keys to be inherited by defining them in the member package with `{key}.workspace = true`","type":"boolean","enum":[true]}},"required":["workspace"],"additionalProperties":false,"x-tombi-table-keys-order":"schema"},"PlaydateMetadata":{"title":"Playdate Package Metadata","description":"Metadata and build configuration.","type":"object","required":["bundle-id"],"properties":{"bundle-id":{"type":"string","description":"A unique identifier for your game, in reverse DNS notation.","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}}},"name":{"type":"string","description":"A game version number, formatted any way you wish, that is displayed to players. It is not used to compute when updates should occur.","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}}},"author":{"type":"string","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}}},"description":{"type":"string","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}}},"version":{"type":"string","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}}},"build-number":{"type":"integer","exclusiveMinimum":0,"x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}},"description":"A monotonically-increasing integer value used to indicate a unique version of your game. This can be set using an automated build process like Continuous Integration to avoid having to set the value by hand.\n\nFor sideloaded games, buildNumber is required and is used to determine when a newer version is available to download."},"image-path":{"type":"string","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}},"description":"A directory of images that will be used by the launcher.\n\nMore in [official documentation](https://sdk.play.date/#pdxinfo)."},"launch-sound-path":{"type":"string","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}},"description":"Should point to the path of a short audio file to be played as the game launch animation is taking place.\n\nMore in [official documentation](https://sdk.play.date/#pdxinfo)."},"content-warning":{"type":"string","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}},"description":"Optional. A content warning that displays when the user launches your game for the first time. The user will have the option of backing out and not launching your game if they choose."},"content-warning2":{"type":"string","x-taplo":{"links":{"key":"https://sdk.play.date/#pdxinfo"}},"description":"Optional. A second content warning that displays on a second screen when the user launches your game for the first time. The user will have the option of backing out and not launching your game if they choose.\n\nNote: `content-warning2` will only display if a `content-warning` attribute is also specified.\n\nThe string displayed on the content warning screen can only be so long before it will be truncated with an \"\u2026\" character. Be sure to keep this in mind when designing your `content-warning` and `content-warning2` text."},"assets":{"anyOf":[{"$ref":"#/definitions/PlaydateMetadataAssetsMap"},{"$ref":"#/definitions/PlaydateMetadataAssetsArray"}]},"dev-assets":{"anyOf":[{"$ref":"#/definitions/PlaydateMetadataAssetsMap"},{"$ref":"#/definitions/PlaydateMetadataAssetsArray"}]},"options":{"$ref":"#/definitions/PlaydateMetadataOptions"},"support":{"type":"object","properties":{},"additionalProperties":true}},"additionalProperties":false,"x-tombi-table-keys-order":"schema","x-taplo":{"initKeys":["bundle-id","name","description","author","image-path","launch-sound-path"],"links":{"key":"https://sdk.play.date/#pdxinfo"}},"x-taplo-info":{"authors":["Alex Koz. (https://github.com/boozook)"]}},"PlaydateMetadataAssetsArray":{"type":"array","title":"Assets list","description":"List of paths to include.","uniqueItems":true,"items":{"title":"Path","description":"Path to include.","type":"string"},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://github.com/boozook/playdate/blob/main/support/build/README.md#assets-list"}}},"PlaydateMetadataAssetsMap":{"type":"object","title":"Assets rules","description":"Rules used to resolve paths to include.","properties":{"options":{"$ref":"#/definitions/PlaydateMetadataAssetsOptions"}},"additionalProperties":{"anyOf":[{"type":"string","title":"Path","description":"Path of files to include. Can be absolute, relative to the crate root, or/and glob.\n\nLeft hand is where to put files, path in the resulting package.\n\nRight hand is a path or pattern to match files to include."},{"type":"boolean","title":"Include","description":"Include or exclude the file or glob-pattern."}]},"x-tombi-table-keys-order":"schema","x-taplo":{"links":{"key":"https://github.com/boozook/playdate/blob/main/support/build/README.md#assets-table"}}},"PlaydateMetadataAssetsOptions":{"type":"object","title":"Assets Configuration","description":"Options for assets paths resolution and how to build assets collection","additionalProperties":false,"properties":{"overwrite":{"type":"boolean","description":"Allow overwriting existing files."},"follow-symlinks":{"type":"boolean"},"method":{"type":"string","enum":["copy","link"]},"dependencies":{"type":"boolean","description":"Allow build assets for dependencies."}},"x-tombi-table-keys-order":"schema","x-taplo":{"links":{"key":"https://github.com/boozook/playdate/blob/main/support/build/README.md#assets-options"}}},"PlaydateMetadataOptions":{"type":"object","title":"Configuration","description":"Package build options.","additionalProperties":true,"properties":{"assets":{"$ref":"#/definitions/PlaydateMetadataAssetsOptions"}},"x-tombi-table-keys-order":"schema","x-taplo":{"links":{"key":"https://github.com/boozook/playdate/blob/main/support/build/README.md#options"}}}},"description":"A schema for Cargo.toml.","properties":{"cargo-features":{"type":"array","items":{"type":"string"},"x-tombi-array-values-order":"version-sort"},"package":{"$ref":"#/definitions/Package"},"project":{"$ref":"#/definitions/Package","description":"[project] is deprecated. Use [package] instead.","deprecated":true,"x-taplo":{"hidden":true}},"workspace":{"$ref":"#/definitions/Workspace"},"lib":{"$ref":"#/definitions/Target","x-taplo":{"docs":{"main":"The library target defines a \"library\" that can be used and linked by other\nlibraries and executables. The filename defaults to `src/lib.rs`, and the name\nof the library defaults to the name of the package. A package can have only\none library. The settings for the library can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[lib]`\ntable in `Cargo.toml`.\n\n```toml\n# Example of customizing the library in Cargo.toml.\n[lib]\ncrate-type = [\"cdylib\"]\nbench = false\n```\n"},"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#library"}}},"bin":{"description":"Binary targets are executable programs that can be run after being compiled.\nThe default binary filename is `src/main.rs`, which defaults to the name of\nthe package. Additional binaries are stored in the [`src/bin/`\ndirectory](https://doc.rust-lang.org/cargo/guide/project-layout.html). The settings for each binary can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[[bin]]` tables in `Cargo.toml`.\n\nBinaries can use the public API of the package's library. They are also linked\nwith the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) defined in `Cargo.toml`.\n\nYou can run individual binaries with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with the `--bin\n<bin-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html) can be used to copy the executable to a\ncommon location.\n\n```toml\n# Example of customizing binaries in Cargo.toml.\n[[bin]]\nname = \"cool-tool\"\ntest = false\nbench = false\n\n[[bin]]\nname = \"frobnicator\"\nrequired-features = [\"frobnicate\"]\n```","type":"array","items":{"$ref":"#/definitions/Target","description":"Binary targets are executable programs that can be run after being compiled.\nThe default binary filename is `src/main.rs`, which defaults to the name of\nthe package. Additional binaries are stored in the [`src/bin/`\ndirectory](https://doc.rust-lang.org/cargo/guide/project-layout.html). The settings for each binary can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[[bin]]` tables in `Cargo.toml`.\n\nBinaries can use the public API of the package's library. They are also linked\nwith the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) defined in `Cargo.toml`.\n\nYou can run individual binaries with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with the `--bin\n<bin-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html) can be used to copy the executable to a\ncommon location.\n\n```toml\n# Example of customizing binaries in Cargo.toml.\n[[bin]]\nname = \"cool-tool\"\ntest = false\nbench = false\n\n[[bin]]\nname = \"frobnicator\"\nrequired-features = [\"frobnicate\"]\n```","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#binaries"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#binaries"}}},"example":{"description":"Files located under the [examples directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are example uses of the functionality provided by the library. When compiled, they are placed in the[ target/debug/examples directory](https://doc.rust-lang.org/cargo/guide/build-cache.html).\n\nExamples can use the public API of the package's library. They are also linked with the [dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in Cargo.toml.\n\nBy default, examples are executable binaries (with a `main()` function). You\ncan specify the [`crate-type` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-crate-type-field) to make an example\nbe compiled as a library:\n\n```toml\n[[example]]\nname = \"foo\"\ncrate-type = [\"staticlib\"]\n```\n\nYou can run individual executable examples with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with\nthe `--example <example-name>` option. Library examples can be built with\n[`cargo build`](https://doc.rust-lang.org/cargo/commands/cargo-build.html) with the `--example <example-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html)\nwith the `--example <example-name>` option can be used to copy executable\nbinaries to a common location. Examples are compiled by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by\ndefault to protect them from bit-rotting. Set [the `test`\nfield](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-test-field) to `true` if you have `#[test]` functions in the\nexample that you want to run with [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html).\n","type":"array","items":{"$ref":"#/definitions/Target","description":"Files located under the [examples directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are example uses of the functionality provided by the library. When compiled, they are placed in the[ target/debug/examples directory](https://doc.rust-lang.org/cargo/guide/build-cache.html).\n\nExamples can use the public API of the package's library. They are also linked with the [dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in Cargo.toml.\n\nBy default, examples are executable binaries (with a `main()` function). You\ncan specify the [`crate-type` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-crate-type-field) to make an example\nbe compiled as a library:\n\n```toml\n[[example]]\nname = \"foo\"\ncrate-type = [\"staticlib\"]\n```\n\nYou can run individual executable examples with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with\nthe `--example <example-name>` option. Library examples can be built with\n[`cargo build`](https://doc.rust-lang.org/cargo/commands/cargo-build.html) with the `--example <example-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html)\nwith the `--example <example-name>` option can be used to copy executable\nbinaries to a common location. Examples are compiled by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by\ndefault to protect them from bit-rotting. Set [the `test`\nfield](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-test-field) to `true` if you have `#[test]` functions in the\nexample that you want to run with [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html).\n","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#examples"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#examples"}}},"test":{"description":"Files located under the [`tests` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are integration\ntests. When you run [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html), Cargo will compile each of these files as\na separate crate, and execute them.\n\nIntegration tests can use the public API of the package's library. They are\nalso linked with the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and\n[`[dev-dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in `Cargo.toml`.\n\nIf you want to share code among multiple integration tests, you can place it\nin a separate module such as `tests/common/mod.rs` and then put `mod common;`\nin each test to import it.\n\nEach integration test results in a separate executable binary, and [`cargo\ntest`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) will run them serially. In some cases this can be inefficient, as it\ncan take longer to compile, and may not make full use of multiple CPUs when\nrunning the tests. If you have a lot of integration tests, you may want to\nconsider creating a single integration test, and split the tests into multiple\nmodules. The libtest harness will automatically find all of the `#[test]`\nannotated functions and run them in parallel. You can pass module names to\n[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) to only run the tests within that module.\n\nBinary targets are automatically built if there is an integration test. This\nallows an integration test to execute the binary to exercise and test its\nbehavior. The `CARGO_BIN_EXE_<name>` [environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) is set when the\nintegration test is built so that it can use the [`env` macro](https://doc.rust-lang.org/std/macro.env.html) to locate the\nexecutable.","type":"array","items":{"$ref":"#/definitions/Target","description":"Files located under the [`tests` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are integration\ntests. When you run [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html), Cargo will compile each of these files as\na separate crate, and execute them.\n\nIntegration tests can use the public API of the package's library. They are\nalso linked with the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and\n[`[dev-dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in `Cargo.toml`.\n\nIf you want to share code among multiple integration tests, you can place it\nin a separate module such as `tests/common/mod.rs` and then put `mod common;`\nin each test to import it.\n\nEach integration test results in a separate executable binary, and [`cargo\ntest`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) will run them serially. In some cases this can be inefficient, as it\ncan take longer to compile, and may not make full use of multiple CPUs when\nrunning the tests. If you have a lot of integration tests, you may want to\nconsider creating a single integration test, and split the tests into multiple\nmodules. The libtest harness will automatically find all of the `#[test]`\nannotated functions and run them in parallel. You can pass module names to\n[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) to only run the tests within that module.\n\nBinary targets are automatically built if there is an integration test. This\nallows an integration test to execute the binary to exercise and test its\nbehavior. The `CARGO_BIN_EXE_<name>` [environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) is set when the\nintegration test is built so that it can use the [`env` macro](https://doc.rust-lang.org/std/macro.env.html) to locate the\nexecutable.","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#integration-tests"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#integration-tests"}}},"bench":{"description":"Benchmarks provide a way to test the performance of your code using the\n[`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html) command. They follow the same structure as [tests](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#tests),\nwith each benchmark function annotated with the `#[bench]` attribute.\nSimilarly to tests:\n\n* Benchmarks are placed in the [`benches` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html).\n* Benchmark functions defined in libraries and binaries have access to the\n  *private* API within the target they are defined in. Benchmarks in the\n  `benches` directory may use the *public* API.\n* [The `bench` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-bench-field) can be used to define which targets\n  are benchmarked by default.\n* [The `harness` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-harness-field) can be used to disable the\n  built-in harness.\n\n> **Note**: The [`#[bench]`\n> attribute](https://doc.rust-lang.org/unstable-book/library-features/test.html) is currently\n> unstable and only available on the [nightly channel](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html). There are some\n> packages available on [crates.io](https://crates.io/keywords/benchmark) that\n> may help with running benchmarks on the stable channel, such as\n> [Criterion](https://crates.io/crates/criterion).","type":"array","items":{"$ref":"#/definitions/Target","description":"Benchmarks provide a way to test the performance of your code using the\n[`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html) command. They follow the same structure as [tests](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#tests),\nwith each benchmark function annotated with the `#[bench]` attribute.\nSimilarly to tests:\n\n* Benchmarks are placed in the [`benches` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html).\n* Benchmark functions defined in libraries and binaries have access to the\n  *private* API within the target they are defined in. Benchmarks in the\n  `benches` directory may use the *public* API.\n* [The `bench` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-bench-field) can be used to define which targets\n  are benchmarked by default.\n* [The `harness` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-harness-field) can be used to disable the\n  built-in harness.\n\n> **Note**: The [`#[bench]`\n> attribute](https://doc.rust-lang.org/unstable-book/library-features/test.html) is currently\n> unstable and only available on the [nightly channel](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html). There are some\n> packages available on [crates.io](https://crates.io/keywords/benchmark) that\n> may help with running benchmarks on the stable channel, such as\n> [Criterion](https://crates.io/crates/criterion).","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#benchmarks"}}},"x-tombi-array-values-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/cargo-targets.html#benchmarks"}}},"dependencies":{"description":"Cargo is configured to look for dependencies on [crates.io](https://crates.io) by default. Only\nthe name and a version string are required in this case. In [the cargo\nguide](https://doc.rust-lang.org/cargo/guide/index.html), we specified a dependency on the `time` crate:\n\n```toml\n[dependencies]\ntime = \"0.1.12\"\n```\n\nThe string `\"0.1.12\"` is a [semver](https://github.com/steveklabnik/semver#requirements) version requirement. Since this\nstring does not have any operators in it, it is interpreted the same way as\nif we had specified `\"^0.1.12\"`, which is called a caret requirement.\n\nA dependency can also be defined by a table with additional options:\n\n```toml\n[dependencies]\ntime = { path = \"../time\", version = \"0.1.12\" }\n```","type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html"}}},"dev-dependencies":{"description":"The format of `[dev-dependencies]` is equivalent to `[dependencies]`:\n\n```toml\n[dev-dependencies]\ntempdir = \"0.3\"\n```\n\nDev-dependencies are not used when compiling\na package for building, but are used for compiling tests, examples, and\nbenchmarks.\n\nThese dependencies are *not* propagated to other packages which depend on this\npackage.\n\nYou can also have target-specific development dependencies by using\n`dev-dependencies` in the target section header instead of `dependencies`. For\nexample:\n\n```toml\n[target.'cfg(unix)'.dev-dependencies]\nmio = \"0.0.1\"\n```\n\n> **Note**: When a package is published, only dev-dependencies that specify a\n> `version` will be included in the published crate. For most use cases,\n> dev-dependencies are not needed when published, though some users (like OS\n> packagers) may want to run tests within a crate, so providing a `version` if\n> possible can still be beneficial.\n","type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies"},"plugins":["crates"],"crates":{"schemas":"dependencies"}}},"dev_dependencies":{"type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"description":"[dev_dependencies] is deprecated. Use [dev-dependencies] instead.","deprecated":true,"x-tombi-table-keys-order":"version-sort","x-taplo":{"hidden":true}},"build-dependencies":{"description":"You can depend on other Cargo-based crates for use in your build scripts.\nDependencies are declared through the `build-dependencies` section of the\nmanifest:\n\n```toml\n[build-dependencies]\ncc = \"1.0.3\"\n```\n\nThe build script **does not** have access to the dependencies listed\nin the `dependencies` or `dev-dependencies` section. Build\ndependencies will likewise not be available to the package itself\nunless listed under the `dependencies` section as well. A package\nitself and its build script are built separately, so their\ndependencies need not coincide. Cargo is kept simpler and cleaner by\nusing independent dependencies for independent purposes.","type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#build-dependencies"},"plugins":["crates"],"crates":{"schemas":"dependencies"}}},"build_dependencies":{"type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"description":"[build_dependencies] is deprecated. Use [build-dependencies] instead.","deprecated":true,"x-tombi-table-keys-order":"version-sort","x-taplo":{"hidden":true}},"target":{"type":"object","x-tombi-table-keys-order":"version-sort","additionalProperties":{"$ref":"#/definitions/Platform"}},"badges":{"description":"[crates.io](https://crates.io) can display various badges for build status, test coverage, etc. for\neach crate. All badges are optional.\n\n- The badges pertaining to build status that are currently available are\n  Appveyor, CircleCI, Cirrus CI, GitLab, Azure DevOps, Travis CI and Bitbucket\n  Pipelines.\n- Available badges pertaining to code test coverage are Codecov and Coveralls.\n- There are also maintenance-related badges based on isitmaintained.com\n  which state the issue resolution time, percent of open issues, and future\n  maintenance intentions.\n\nMost badge specifications require a `repository` key. It is expected to be in\n`user/repo` format.\n\n```toml\n[badges]\n\n# Appveyor: `repository` is required. `branch` is optional; default is `master`\n# `service` is optional; valid values are `github` (default), `bitbucket`, and\n# `gitlab`; `id` is optional; you can specify the appveyor project id if you\n# want to use that instead. `project_name` is optional; use when the repository\n# name differs from the appveyor project name.\nappveyor = { repository = \"...\", branch = \"master\", service = \"github\" }\n\n# Circle CI: `repository` is required. `branch` is optional; default is `master`\ncircle-ci = { repository = \"...\", branch = \"master\" }\n\n# Cirrus CI: `repository` is required. `branch` is optional; default is `master`\ncirrus-ci = { repository = \"...\", branch = \"master\" }\n\n# GitLab: `repository` is required. `branch` is optional; default is `master`\ngitlab = { repository = \"...\", branch = \"master\" }\n\n# Azure DevOps: `project` is required. `pipeline` is required. `build` is optional; default is `1`\n# Note: project = `organization/project`, pipeline = `name_of_pipeline`, build = `definitionId`\nazure-devops = { project = \"...\", pipeline = \"...\", build=\"2\" }\n\n# Travis CI: `repository` in format \"<user>/<project>\" is required.\n# `branch` is optional; default is `master`\ntravis-ci = { repository = \"...\", branch = \"master\" }\n\n# Bitbucket Pipelines: `repository` is required. `branch` is required\nbitbucket-pipelines = { repository = \"...\", branch = \"master\" }\n\n# Codecov: `repository` is required. `branch` is optional; default is `master`\n# `service` is optional; valid values are `github` (default), `bitbucket`, and\n# `gitlab`.\ncodecov = { repository = \"...\", branch = \"master\", service = \"github\" }\n\n# Coveralls: `repository` is required. `branch` is optional; default is `master`\n# `service` is optional; valid values are `github` (default) and `bitbucket`.\ncoveralls = { repository = \"...\", branch = \"master\", service = \"github\" }\n\n# Is it maintained resolution time: `repository` is required.\nis-it-maintained-issue-resolution = { repository = \"...\" }\n\n# Is it maintained percentage of open issues: `repository` is required.\nis-it-maintained-open-issues = { repository = \"...\" }\n\n# Maintenance: `status` is required. Available options are:\n# - `actively-developed`: New features are being added and bugs are being fixed.\n# - `passively-maintained`: There are no plans for new features, but the maintainer intends to\n#   respond to issues that get filed.\n# - `as-is`: The crate is feature complete, the maintainer does not intend to continue working on\n#   it or providing support, but it works for the purposes it was designed for.\n# - `experimental`: The author wants to share it with the community but is not intending to meet\n#   anyone's particular use case.\n# - `looking-for-maintainer`: The current maintainer would like to transfer the crate to someone\n#   else.\n# - `deprecated`: The maintainer does not recommend using this crate (the description of the crate\n#   can describe why, there could be a better solution available or there could be problems with\n#   the crate that the author does not want to fix).\n# - `none`: Displays no badge on crates.io, since the maintainer has not chosen to specify\n#   their intentions, potential crate users will need to investigate on their own.\nmaintenance = { status = \"...\" }\n```","type":"object","additionalProperties":{"type":"object","additionalProperties":{"type":"string"},"x-tombi-table-keys-order":"version-sort"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/manifest.html#the-badges-section"}}},"features":{"description":"Cargo supports features to allow expression of:\n\n* conditional compilation options (usable through `cfg` attributes);\n* optional dependencies, which enhance a package, but are not required; and\n* clusters of optional dependencies, such as `postgres-all`, that would include the\n  `postgres` package, the `postgres-macros` package, and possibly other packages\n  (such as development-time mocking libraries, debugging tools, etc.).\n\nA feature of a package is either an optional dependency, or a set of other\nfeatures.\n","type":"object","additionalProperties":{"type":"array","items":{"type":"string"},"x-tombi-array-values-order":"version-sort"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/features.html"}}},"lints":{"description":"Override the default level of lints from different tools by assigning them to a new level in a table.","anyOf":[{"$ref":"#/definitions/Lints"},{"type":"object","properties":{"workspace":{"type":"boolean","description":"Inherit lints from the workspace manifest."}},"required":["workspace"],"additionalProperties":false,"x-tombi-table-keys-order":"version-sort"}],"x-taplo":{"links":{"key":"https://doc.rust-lang.org/stable/cargo/reference/manifest.html#the-lints-section"}}},"patch":{"description":"The `[patch]` section of `Cargo.toml` can be used to override dependencies\nwith other copies. The syntax is similar to the\n[`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) section.\n\n","type":"object","additionalProperties":{"type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"links":{"key":"https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section"}}},"replace":{"type":"object","additionalProperties":{"$ref":"#/definitions/Dependency"},"x-tombi-table-keys-order":"version-sort","x-taplo":{"hidden":true}},"profile":{"$ref":"#/definitions/Profiles"}},"title":"Cargo.toml","type":"object","additionalProperties":false,"x-tombi-table-keys-order":"schema","x-taplo-info":{"authors":["tamasfe (https://github.com/tamasfe)"],"patterns":["^(.*(/|\\\\)Cargo\\.toml|Cargo\\.toml)$"]}}
</schema>

[User] Provide a JSON object that satisfies the schema "Cargo.toml". Here are the required top‑level fields: none (all optional). Return only the valid JSON object.

Build

The `build` field specifies a file in the package root which is a [build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) for building native code. More information can be found in the [build script guide](https://doc.rust-lang.org/cargo/reference/build-scripts.html).

```toml
[package]
# ...
build = "build.rs"
```

The default is `"build.rs"`, which loads the script from a file named
`build.rs` in the root of the package. Use `build = "custom_build_name.rs"` to
specify a path to a different file or `build = false` to disable automatic
detection of the build script.

Path to the build file.

Automatically detect the build file (`build.rs`).

Disable automatic detection of the build file.

Debug Level

The `debug` setting controls the [`-C debuginfo` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#debuginfo) which controls the
amount of debug information included in the compiled binary.

none line-directives-only line-tables-only limited full

No debug info at all, default for `release` profile

Debug info without type or variable-level information. Generates more detailed module-level info than `line-tables-only`.

Full debug info, default for `dev` profile

Line info directives only. For the nvptx* targets this enables [profiling](https://reviews.llvm.org/D46061). For other use cases, `line-tables-only` is the better, more compatible choice.

Line tables only. Generates the minimal amount of debug info for backtraces with filename/line number info, but not anything else, i.e. no variable or function parameter info.

Dependency

Detailed Dependency

Inherit this dependency from the workspace manifest.

Specify the Git branch to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

Use the default features of the dependency.

"default_features" is deprecated. Use "default-features" instead.

List of features to activate in the dependency.

To depend on a library located in a `git` repository, the minimum information
you need to specify is the location of the repository with the `git` key:

```toml
[dependencies]
rand = { git = "https://github.com/rust-lang-nursery/rand" }
```

Cargo will fetch the `git` repository at this location then look for a
`Cargo.toml` for the requested crate anywhere inside the `git` repository
(not necessarily at the root - for example, specifying a member crate name
of a workspace and setting `git` to the repository containing the workspace).

Since we haven't specified any other information, Cargo assumes that
we intend to use the latest commit on the main branch to build our package.
You can combine the `git` key with the `rev`, `tag`, or `branch` keys to
specify something else. Here's an example of specifying that you want to use
the latest commit on a branch named `next`:

```toml
[dependencies]
rand = { git = "https://github.com/rust-lang-nursery/rand", branch = "next" }
```

See [Git Authentication](https://doc.rust-lang.org/cargo/appendix/git-authentication.html) for help with git authentication for private repos.

> **Note**: [crates.io](https://crates.io/) does not allow packages to be published with `git`
> dependencies (`git` [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) are ignored). See the [Multiple
> locations](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations) section for a fallback alternative.

Mark the dependency as optional.

Optional dependencies can be activated through features.

Specify the name of the package.

When writing a `[dependencies]` section in `Cargo.toml` the key you write for a
dependency typically matches up to the name of the crate you import from in the
code. For some projects, though, you may wish to reference the crate with a
different name in the code regardless of how it's published on crates.io. For
example you may wish to:

* Avoid the need to  `use foo as bar` in Rust source.
* Depend on multiple versions of a crate.
* Depend on crates with the same name from different registries.

To support this Cargo supports a `package` key in the `[dependencies]` section
of which package should be depended on:

```toml
[package]
name = "mypackage"
version = "0.0.1"

[dependencies]
foo = "0.1"
bar = { git = "https://github.com/example/project", package = "foo" }
baz = { version = "0.1", registry = "custom", package = "foo" }
```

In this example, three crates are now available in your Rust code:

```rust
extern crate foo; // crates.io
extern crate bar; // git repository
extern crate baz; // registry `custom`
```

All three of these crates have the package name of `foo` in their own
`Cargo.toml`, so we're explicitly using the `package` key to inform Cargo that
we want the `foo` package even though we're calling it something else locally.
The `package` key, if not specified, defaults to the name of the dependency
being requested.

Cargo supports **path dependencies** which are typically sub-crates that live within one repository.
Let's start off by making a new crate inside of our `hello_world` package:

```console
# inside of hello_world/
$ cargo new hello_utils
```

This will create a new folder `hello_utils` inside of which a `Cargo.toml` and
`src` folder are ready to be configured. In order to tell Cargo about this, open
up `hello_world/Cargo.toml` and add `hello_utils` to your dependencies:

```toml
[dependencies]
hello_utils = { path = "hello_utils" }
```

This tells Cargo that we depend on a crate called `hello_utils` which is found
in the `hello_utils` folder (relative to the `Cargo.toml` it's written in).

To specify a dependency from a registry other than [crates.io](https://crates.io), first the
registry must be configured in a `.cargo/config.toml` file. See the [registries
documentation](https://doc.rust-lang.org/cargo/reference/registries.html) for more information. In the dependency, set the `registry` key
to the name of the registry to use.

```toml
[dependencies]
some-crate = { version = "1.0", registry = "my-registry" }
```

> **Note**: [crates.io](https://crates.io) does not allow packages to be published with
> dependencies on other registries.

Specify the Git revision to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#choice-of-commit).

This can be a commit hash, or a named reference exposed by the remote repository. GitHub Pull Requests may be specified using the `refs/pull/ID/head` format.

Specify the Git tag to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

Detailed Lint

The priority that controls which lints or [lint groups](https://doc.rust-lang.org/rustc/lints/groups.html) override other lint groups. Lower (particularly negative) numbers have lower priority, being overridden by higher numbers, and show up first on the command-line to tools like rustc.

Edition

The `edition` key affects which edition your package is compiled with. Cargo
will always generate packages via [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) with the `edition` key set to the
latest edition. Setting the `edition` key in `[package]` will affect all
targets/crates in the package, including test suites, benchmarks, binaries,
examples, etc.

Inherits

In addition to the built-in profiles, additional custom profiles can be defined.

Lint

Lint Level

Specify the [lint level](https://doc.rust-lang.org/rustc/lints/levels.html) for a lint or lint group.

`forbid` is the same as `deny` in that a lint at this level will produce an error, but unlike the `deny` level, the `forbid` level can not be overridden to be anything lower than an error. However, lint levels may still be capped with [`--cap-lints`](https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints) so `rustc --cap-lints warn` will make lints set to `forbid` just warn.

The `deny` lint level produces an error if you violate the lint.

The `warn` lint level produces a warning if you violate the lint.

The `allow` lint level ignores violations of the lint.

Lint settings for the Rust compiler. See the Rust compiler's [individual lints](https://doc.rust-lang.org/rustc/lints/listing/index.html) or [lint groups](https://doc.rust-lang.org/rustc/lints/groups.html).

Lint settings for [Rustdoc](https://doc.rust-lang.org/rustdoc/). See Rustdoc's [individual lints](https://doc.rust-lang.org/rustdoc/lints.html) (rustdoc does not have lint groups)

Lint settings for [Clippy](https://doc.rust-lang.org/clippy/). See Clippy's [individual lints](https://rust-lang.github.io/rust-clippy/master/index.html) or [lint groups](https://doc.rust-lang.org/clippy/lints.html) documentation.

Lto

The `lto` setting controls the [`-C lto` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#lto) which controls LLVM's [link time optimizations](https://llvm.org/docs/LinkTimeOptimization.html). LTO can produce better optimized code, using
whole-program analysis, at the cost of longer linking time.

See also the [`-C linker-plugin-lto`](https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-plugin-lto) `rustc` flag for cross-language LTO.

Performs "fat" LTO which attempts to perform optimizations across all crates within the dependency graph.

Performs ["thin" LTO](http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html). This is similar to "fat", but takes
substantially less time to run while still achieving performance gains
similar to "fat".

Performs "thin local LTO" which performs "thin" LTO on the local
crate only across its [codegen units](https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units). No LTO is performed
if codegen units is 1 or [opt-level](https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level) is 0.

Meta Build

Resolver

A different feature resolver algorithm can be used by specifying the resolver version in Cargo.toml like this:

[package]
name = "my-package"
version = "1.0.0"
resolver = "2"

The version "1" resolver is the original resolver that shipped with Cargo up to version 1.50. The default is "2" if the root package specifies edition = "2021" or a newer edition. Otherwise the default is "1".

The version "2" resolver introduces changes in feature unification. See the features chapter for more details.

The resolver is a global option that affects the entire workspace. The resolver version in dependencies is ignored, only the value in the top-level package will be used. If using a virtual workspace, the version should be specified in the [workspace] table, for example:

[workspace]
members = ["member1", "member2"]
resolver = "2"

Optimization Level

The `opt-level` setting controls the [`-C opt-level` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#opt-level) which controls the level
of optimization. Higher optimization levels may produce faster runtime code at
the expense of longer compiler times. Higher levels may also change and
rearrange the compiled code which may make it harder to use with a debugger.

It is recommended to experiment with different levels to find the right
balance for your project. There may be surprising results, such as level `3`
being slower than `2`, or the `"s"` and `"z"` levels not being necessarily
smaller. You may also want to reevaluate your settings over time as newer
versions of `rustc` changes optimization behavior.

See also [Profile Guided Optimization](https://doc.rust-lang.org/rustc/profile-guided-optimization.html) for more advanced optimization
techniques.

No optimizations, also turns on [`cfg(debug_assertions)`](https://doc.rust-lang.org/cargo/reference/profiles.html#debug-assertions).

Optimize for binary size, but also turn off loop vectorization.

Package

The only field required by Cargo is [`name`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-name-field).
 If publishing to a registry, the registry may
require additional fields. See the notes below and [the publishing chapter](https://doc.rust-lang.org/cargo/reference/publishing.html) for requirements for publishing to [crates.io](https://crates.io/).

The package name is an identifier used to refer to the package. It is used
when listed as a dependency in another package, and as the default name of
inferred lib and bin targets.

The name must use only [alphanumeric](https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric) characters or `-` or `_`, and cannot be empty.
Note that [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) and [`cargo init`](https://doc.rust-lang.org/cargo/commands/cargo-init.html) impose some additional restrictions on
the package name, such as enforcing that it is a valid Rust identifier and not
a keyword. [crates.io](https://crates.io) imposes even more restrictions, such as
enforcing only ASCII characters, not a reserved name, not a special Windows
name such as "nul", is not too long, etc.

Semantic Version

Cargo bakes in the concept of [Semantic Versioning](https://semver.org/), so make sure you follow some basic rules:

* Before you reach 1.0.0, anything goes, but if you make breaking changes,
    increment the minor version. In Rust, breaking changes include adding fields to
    structs or variants to enums.
* After 1.0.0, only make breaking changes when you increment the major version.
    Don't break the build.
* After 1.0.0, don't add any new public API (no new `pub` anything) in patch-level
    versions. Always increment the minor version if you add any new `pub` structs,
    traits, fields, types, functions, methods or anything else.
* Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.

Authors

The `authors` field lists people or organizations that are considered the
"authors" of the package. The exact meaning is open to interpretation — it may
list the original or primary authors, current maintainers, or owners of the
package. These names will be listed on the crate's page on
[crates.io](https://crates.io). An optional email address may be included within angled
brackets at the end of each author.

> **Note**: [crates.io](https://crates.io) requires at least one author to be listed.

Edition

RustVersion

The `rust-version` field is an optional key that tells cargo what version of the
Rust language and compiler your package can be compiled with. If the currently
selected version of the Rust compiler is older than the stated version, cargo
will exit with an error, telling the user what version is required.

The first version of Cargo that supports this field was released with Rust 1.56.0.
In older releases, the field will be ignored, and Cargo will display a warning.

```toml
[package]
# ...
rust-version = "1.56"
```

The Rust version must be a bare version number with two or three components; it
cannot include semver operators or pre-release identifiers. Compiler pre-release
identifiers such as -nightly will be ignored while checking the Rust version.
The `rust-version` must be equal to or newer than the version that first
introduced the configured `edition`.

The `rust-version` may be ignored using the `--ignore-rust-version` option.

Setting the `rust-version` key in `[package]` will affect all targets/crates in
the package, including test suites, benchmarks, binaries, examples, etc.

Description

The description is a short blurb about the package. [crates.io](https://crates.io) will display
this with your package. This should be plain text (not Markdown).

```toml
[package]
# ...
description = "A short description of my package"
```

> **Note**: [crates.io](https://crates.io) requires the `description` to be set.

Documentation

The `documentation` field specifies a URL to a website hosting the crate's
documentation. If no URL is specified in the manifest file, [crates.io](https://crates.io) will
automatically link your crate to the corresponding [docs.rs](https://docs.rs) page.

```toml
[package]
# ...
documentation = "https://docs.rs/bitflags"
```

Readme

The `readme` field should be the path to a file in the package root (relative
to this `Cargo.toml`) that contains general information about the package.
This file will be transferred to the registry when you publish. [crates.io](https://crates.io)
will interpret it as Markdown and render it on the crate's page.

```toml
[package]
# ...
readme = "README.md"
```

If no value is specified for this field, and a file named `README.md`,
`README.txt` or `README` exists in the package root, then the name of that
file will be used. You can suppress this behavior by setting this field to
`false`. If the field is set to `true`, a default value of `README.md` will
be assumed.

Homepage

The `homepage` field should be a URL to a site that is the home page for your
package.

```toml
[package]
# ...
homepage = "https://serde.rs/"
```

Repository

The `repository` field should be a URL to the source repository for your
package.

```toml
[package]
# ...
repository = "https://github.com/rust-lang/cargo/"
```

License

The `license` field contains the name of the software license that the package
is released under.

[crates.io](https://crates.io/) interprets the `license` field as an [SPDX 2.1 license
expression](https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60). The name must be a known license
from the [SPDX license list 3.6](https://github.com/spdx/license-list-data/tree/v3.6). Parentheses are not
currently supported. See the [SPDX site](https://spdx.org/license-list) for more information.

SPDX license expressions support AND and OR operators to combine multiple
licenses.

```toml
[package]
# ...
license = "MIT OR Apache-2.0"
```

Using `OR` indicates the user may choose either license. Using `AND` indicates
the user must comply with both licenses simultaneously. The `WITH` operator
indicates a license with a special exception. Some examples:

* `MIT OR Apache-2.0`
* `LGPL-2.1 AND MIT AND BSD-2-Clause`
* `GPL-2.0+ WITH Bison-exception-2.2`

If a package is using a nonstandard license, then the `license-file` field may
be specified in lieu of the `license` field.

LicenseFile

The `license-file` field contains the path to a file
containing the text of the license (relative to this `Cargo.toml`).

```toml
[package]
# ...
license-file = "LICENSE.txt"
```

> **Note**: [crates.io](https://crates.io) requires either `license` or `license-file` to be set.

Keywords

The `keywords` field is an array of strings that describe this package. This
can help when searching for the package on a registry, and you may choose any
words that would help someone find this crate.

```toml
[package]
# ...
keywords = ["gamedev", "graphics"]
```

> **Note**: [crates.io](https://crates.io) has a maximum of 5 keywords. Each keyword must be
> ASCII text, start with a letter, and only contain letters, numbers, `_` or
> `-`, and have at most 20 characters.

Categories

The `categories` field is an array of strings of the categories this package
belongs to.

```toml
categories = ["command-line-utilities", "development-tools::cargo-plugins"]
```

> **Note**: [crates.io](https://crates.io) has a maximum of 5 categories. Each category should
> match one of the strings available at https://crates.io/category_slugs, and
> must match exactly.

The `workspace` field can be used to configure the workspace that this package
will be a member of. If not specified this will be inferred as the first
Cargo.toml with `[workspace]` upwards in the filesystem. Setting this is
useful if the member is not inside a subdirectory of the workspace root.

```toml
[package]
# ...
workspace = "path/to/workspace/root"
```

This field cannot be specified if the manifest already has a `[workspace]`
table defined. That is, a crate cannot both be a root crate in a workspace
(contain `[workspace]`) and also be a member crate of another workspace
(contain `package.workspace`).

For more information, see the [workspaces chapter](https://doc.rust-lang.org/cargo/reference/workspaces.html).

The `links` field specifies the name of a native library that is being linked
to. More information can be found in the [`links`](https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key) section of the build
script guide.

```toml
[package]
# ...
links = "foo"
```

Exclude

You can explicitly specify that a set of file patterns should be ignored or
included for the purposes of packaging. The patterns specified in the
`exclude` field identify a set of files that are not included, and the
patterns in `include` specify files that are explicitly included.

The patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:

- `foo` matches any file or directory with the name `foo` anywhere in the
  package. This is equivalent to the pattern `**/foo`.
- `/foo` matches any file or directory with the name `foo` only in the root of
  the package.
- `foo/` matches any *directory* with the name `foo` anywhere in the package.
- Common glob patterns like `*`, `?`, and `[]` are supported:
  - `*` matches zero or more characters except `/`.  For example, `*.html`
    matches any file or directory with the `.html` extension anywhere in the
    package.
  - `?` matches any character except `/`. For example, `foo?` matches `food`,
    but not `foo`.
  - `[]` allows for matching a range of characters. For example, `[ab]`
    matches either `a` or `b`. `[a-z]` matches letters a through z.
- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the
  file or directory `bar` anywhere that is directly under directory `foo`.
- `/**` suffix matches everything inside. For example, `foo/**` matches all
  files inside directory `foo`, including all files in subdirectories below
  `foo`.
- `/**/` matches zero or more directories. For example, `a/**/b` matches
  `a/b`, `a/x/b`, `a/x/y/b`, and so on.
- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and
  `!foo.rs` would match all files with the `.rs` extension inside the `src`
  directory, except for any file named `foo.rs`.

If git is being used for a package, the `exclude` field will be seeded with
the `gitignore` settings from the repository.

```toml
[package]
# ...
exclude = ["build/**/*.o", "doc/**/*.html"]
```

```toml
[package]
# ...
include = ["src/**/*", "Cargo.toml"]
```

The options are mutually exclusive: setting `include` will override an
`exclude`. Note that `include` must be an exhaustive list of files as otherwise
necessary source files may not be included. The package's `Cargo.toml` is
automatically included.

The include/exclude list is also used for change tracking in some situations.
For targets built with `rustdoc`, it is used to determine the list of files to
track to determine if the target should be rebuilt. If the package has a
[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the
include/exclude list is used for tracking if the build script should be re-run
if any of those files change.

Publish

The `publish` field can be used to prevent a package from being published to a package registry (like *crates.io*) by mistake, for instance to keep a package
private in a company.

```toml
[package]
# ...
publish = false
```

The value may also be an array of strings which are registry names that are
allowed to be published to.

```toml
[package]
# ...
publish = ["some-registry-name"]
```

Cargo by default will warn about unused keys in `Cargo.toml` to assist in
detecting typos and such. The `package.metadata` table, however, is completely
ignored by Cargo and will not be warned about. This section can be used for
tools which would like to store package configuration in `Cargo.toml`. For
example:

```toml
[package]
name = "..."
# ...

# Metadata used when generating an Android APK, for example.
[package.metadata.android]
package-name = "my-awesome-android-app"
assets = "path/to/static"
```

The `default-run` field in the `[package]` section of the manifest can be used
to specify a default binary picked by [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html). For example, when there is
both `src/bin/a.rs` and `src/bin/b.rs`:

```toml
[package]
default-run = "a"
```

Disable automatic discovery of `bin` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

To prevent Cargo from inferring `src/bin/mod.rs` as an executable, set
this to `false` to disable auto-discovery.

Disable automatic discovery of `example` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

Disable automatic discovery of `test` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

Disable automatic discovery of `bench` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

Sets whether the current package is a teapot or something else that is not capable of brewing tea.

Panic

The `panic` setting controls the [`-C panic` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#panic) which controls which panic
strategy to use.

When set to `"unwind"`, the actual value depends on the default of the target
platform. For example, the NVPTX platform does not support unwinding, so it
always uses `"abort"`.

Tests, benchmarks, build scripts, and proc macros ignore the `panic` setting.
The `rustc` test harness currently requires `unwind` behavior. See the
[`panic-abort-tests`](https://doc.rust-lang.org/cargo/reference/unstable.html#panic-abort-tests) unstable flag which enables `abort` behavior.

Additionally, when using the `abort` strategy and building a test, all of the
dependencies will also be forced to built with the `unwind` strategy.

Unwind the stack upon panic.
Terminate the process upon panic.

Platform

Cargo is configured to look for dependencies on [crates.io](https://crates.io) by default. Only
the name and a version string are required in this case. In [the cargo
guide](https://doc.rust-lang.org/cargo/guide/index.html), we specified a dependency on the `time` crate:

```toml
[dependencies]
time = "0.1.12"
```

The string `"0.1.12"` is a [semver](https://github.com/steveklabnik/semver#requirements) version requirement. Since this
string does not have any operators in it, it is interpreted the same way as
if we had specified `"^0.1.12"`, which is called a caret requirement.

A dependency can also be defined by a table with additional options:

```toml
[dependencies]
time = { path = "../time", version = "0.1.12" }
```

The format of `[dev-dependencies]` is equivalent to `[dependencies]`:

```toml
[dev-dependencies]
tempdir = "0.3"
```

Dev-dependencies are not used when compiling
a package for building, but are used for compiling tests, examples, and
benchmarks.

These dependencies are *not* propagated to other packages which depend on this
package.

You can also have target-specific development dependencies by using
`dev-dependencies` in the target section header instead of `dependencies`. For
example:

```toml
[target.'cfg(unix)'.dev-dependencies]
mio = "0.0.1"
```

> **Note**: When a package is published, only dev-dependencies that specify a
> `version` will be included in the published crate. For most use cases,
> dev-dependencies are not needed when published, though some users (like OS
> packagers) may want to run tests within a crate, so providing a `version` if
> possible can still be beneficial.

You can depend on other Cargo-based crates for use in your build scripts.
Dependencies are declared through the `build-dependencies` section of the
manifest:

```toml
[build-dependencies]
cc = "1.0.3"
```

The build script **does not** have access to the dependencies listed
in the `dependencies` or `dev-dependencies` section. Build
dependencies will likewise not be available to the package itself
unless listed under the `dependencies` section as well. A package
itself and its build script are built separately, so their
dependencies need not coincide. Cargo is kept simpler and cleaner by
using independent dependencies for independent purposes.

Build Override

Profile settings can be overridden for specific packages and build-time
crates. To override the settings for a specific package, use the `package`
table to change the settings for the named package:

```toml
# The `foo` package will use the -Copt-level=3 flag.
[profile.dev.package.foo]
opt-level = 3
```

The package name is actually a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can
target individual versions of a package with syntax such as
`[profile.dev.package."foo:2.1.0"]`.

To override the settings for all dependencies (but not any workspace member),
use the `"*"` package name:

```toml
# Set the default for dependencies.
[profile.dev.package."*"]
opt-level = 2
```

To override the settings for build scripts, proc macros, and their
dependencies, use the `build-override` table:

```toml
# Set the settings for build scripts and proc-macros.
[profile.dev.build-override]
opt-level = 3
```

> Note: When a dependency is both a normal dependency and a build dependency,
> Cargo will try to only build it once when `--target` is not specified. When
> using `build-override`, the dependency may need to be built twice, once as a
> normal dependency and once with the overridden build settings. This may
> increase initial build times.

Profile with Build Override

SplitDebuginfo

The split-debuginfo setting controls the -C split-debuginfo flag which controls whether debug information, if generated, is either placed in the executable itself or adjacent to it. This can be useful for reducing the size of the executable, but may make it harder to debug the executable.

This is the default for platforms with ELF binaries and windows-gnu (not Windows MSVC and not macOS). This typically means that DWARF debug information can be found in the final artifact in sections of the executable. This option is not supported on Windows MSVC. On macOS this options prevents the final execution of dsymutil to generate debuginfo.

This is the default for Windows MSVC and macOS. The term "packed" here means that all the debug information is packed into a separate file from the main executable. On Windows MSVC this is a *.pdb file, on macOS this is a *.dSYM folder, and on other platforms this is a *.dwp file.

This means that debug information will be found in separate files for each compilation unit (object file). This is not supported on Windows MSVC. On macOS this means the original object files will contain debug information. On other Unix platforms this means that *.dwo files will contain debug information.

The strip option controls the -C strip flag, which directs rustc to strip either symbols or debuginfo from a binary.

Equivalent to "symbols"

Equivalent to "none"

The `debug-assertions` setting controls the [`-C debug-assertions` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#debug-assertions) which
turns `cfg(debug_assertions)` [conditional compilation](https://doc.rust-lang.org/reference/conditional-compilation.html#debug_assertions) on or off. Debug
assertions are intended to include runtime validation which is only available
in debug/development builds. These may be things that are too expensive or
otherwise undesirable in a release build. Debug assertions enables the
[`debug_assert!` macro](https://doc.rust-lang.org/std/macro.debug_assert.html) in the standard library.

The `overflow-checks` setting controls the [`-C overflow-checks` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks) which
controls the behavior of [runtime integer overflow](https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow). When overflow-checks are
enabled, a panic will occur on overflow.

The `incremental` setting controls the [`-C incremental` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#incremental) which controls
whether or not incremental compilation is enabled. Incremental compilation
causes `rustc` to to save additional information to disk which will be reused
when recompiling the crate, improving re-compile times. The additional
information is stored in the `target` directory.

The valid options are:

* `true`: enabled
* `false`: disabled

Incremental compilation is only used for workspace members and "path"
dependencies.

The incremental value can be overridden globally with the `CARGO_INCREMENTAL`
[environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html) or the [`build.incremental`](https://doc.rust-lang.org/cargo/reference/config.html#buildincremental) config variable.

The `codegen-units` setting controls the [`-C codegen-units` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units) which
controls how many "code generation units" a crate will be split into. More
code generation units allows more of a crate to be processed in parallel
possibly reducing compile time, but may produce slower code.

This option takes an integer greater than 0.

The default is 256 for [incremental](https://doc.rust-lang.org/cargo/reference/profiles.html#incremental) builds, and 16 for
non-incremental builds.

The `rpath` setting controls the [`-C rpath` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#rpath) which controls
whether or not [`rpath`](https://en.wikipedia.org/wiki/Rpath) is enabled.

Package-specific overrides.

The package name is a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can
target individual versions of a package with syntax such as `[profile.dev.package."foo:2.1.0"]`.

Profile

Profiles

Profiles provide a way to alter the compiler settings, influencing things like optimizations and debugging symbols.

Cargo has 4 built-in profiles: dev, release, test, and bench. It automatically chooses the profile based on which command is being run, the package and target that is being built, and command-line flags like --release.

Publish

A boolean indicating whether the package can be published.

The package can be published.
The package cannot be published.

An array of registry names.

Readme

The `readme` field should be the path to a file in the package root (relative
to this `Cargo.toml`) that contains general information about the package.

Use the `README.md` file.
Do not use the default `README.md` file

Semantic Version

Semantic Version Requirement

The [version requirement](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) of the target dependency.

Target

The `bench` field indicates whether or not the target is benchmarked by
default by [`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html). The default is `true` for lib, bins, and
benchmarks.

The `crate-type` field defines the [crate types](https://doc.rust-lang.org/reference/linkage.html) that will be generated by the
target. It is an array of strings, allowing you to specify multiple crate
types for a single target. This can only be specified for libraries and
examples. Binaries, tests, and benchmarks are always the "bin" crate type.

The available options are `bin`, `lib`, `rlib`, `dylib`, `cdylib`,
`staticlib`, and `proc-macro`. You can read more about the different crate
types in the [Rust Reference Manual](https://doc.rust-lang.org/reference/linkage.html).

A runnable executable will be produced. This requires that there is a `main` function in the crate which
will be run when the program begins executing. This will link in all Rust and
native dependencies, producing a distributable binary.

A Rust library will be produced.
This is an ambiguous concept as to what exactly is produced because a library
can manifest itself in several forms. The purpose of this generic `lib` option
is to generate the "compiler recommended" style of library. The output library
will always be usable by rustc, but the actual type of library may change from
time-to-time. The remaining output types are all different flavors of
libraries, and the `lib` type can be seen as an alias for one of them (but the
actual one is compiler-defined).

A "Rust library" file will be produced. This is used as an intermediate artifact and can be thought of as a
"static Rust library". These `rlib` files, unlike `staticlib` files, are
interpreted by the compiler in future linkage. This essentially means
that `rustc` will look for metadata in `rlib` files like it looks for metadata
in dynamic libraries. This form of output is used to produce statically linked
executables as well as `staticlib` outputs.

A dynamic Rust library will be produced. This is different from the `lib` output type in that this forces
dynamic library generation. The resulting dynamic library can be used as a
dependency for other libraries and/or executables. This output type will
create `*.so` files on linux, `*.dylib` files on osx, and `*.dll` files on
windows.

A dynamic system library will be produced. This is used when compiling
a dynamic library to be loaded from another language.  This output type will
create `*.so` files on Linux, `*.dylib` files on macOS, and `*.dll` files on
Windows.

A static system library will be produced. This is different from other library outputs in that
the compiler will never attempt to link to `staticlib` outputs. The
purpose of this output type is to create a static library containing all of
the local crate's code along with all upstream dependencies. The static
library is actually a `*.a` archive on linux and osx and a `*.lib` file on
windows. This format is recommended for use in situations such as linking
Rust code into an existing non-Rust application because it will not have
dynamic dependencies on other Rust code.

The output produced is not specified, but if a `-L` path is provided to it then the
compiler will recognize the output artifacts as a macro and it can be loaded
for a program. Crates compiled with this crate type  must only export
[procedural macros](https://doc.rust-lang.org/reference/procedural-macros.html). The compiler will automatically set the `proc_macro`
[configuration option](https://doc.rust-lang.org/reference/conditional-compilation.html). The crates are always compiled with the same target
that the compiler itself was built with. For example, if you are executing
the compiler from Linux with an `x86_64` CPU, the target will be
`x86_64-unknown-linux-gnu` even if the crate is a dependency of another crate
being built for a different target.

The `doc` field indicates whether or not the target is included in the
documentation generated by [`cargo doc`](https://doc.rust-lang.org/cargo/commands/cargo-doc.html) by default. The default is `true` for
libraries and binaries.

> **Note**: The binary will be skipped if its name is the same as the lib
> target.

The `doctest` field indicates whether or not [documentation examples](https://doc.rust-lang.org/rustdoc/documentation-tests.html) are
tested by default by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html). This is only relevant for libraries, it
has no effect on other sections. The default is `true` for the library.

The `harness` field indicates that the [`--test` flag](https://doc.rust-lang.org/rustc/command-line-arguments.html#option-test) will be passed to
`rustc` which will automatically include the libtest library which is the
driver for collecting and running tests marked with the [`#[test]` attribute](https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute) or benchmarks with the `#[bench]` attribute. The
default is `true` for all targets.

If set to `false`, then you are responsible for defining a `main()` function
to run tests and benchmarks.

Tests have the [`cfg(test)` conditional expression](https://doc.rust-lang.org/reference/conditional-compilation.html#test) enabled whether
or not the harness is enabled.

The `name` field specifies the name of the target, which corresponds to the
filename of the artifact that will be generated. For a library, this is the
crate name that dependencies will use to reference it.

For the `[lib]` and the default binary (`src/main.rs`), this defaults to the
name of the package, with any dashes replaced with underscores. For other
[auto discovered](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery) targets, it defaults to the
directory or file name.

This is required for all targets except `[lib]`.

The `path` field specifies where the source for the crate is located, relative
to the `Cargo.toml` file.

If not specified, the [inferred path](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery) is used based on
the target name.

The `proc-macro` field indicates that the library is a [procedural macro](https://doc.rust-lang.org/book/ch19-06-macros.html)
([reference](https://doc.rust-lang.org/reference/procedural-macros.html)). This is only valid for the `[lib]`
target.

The `required-features` field specifies which [features](https://doc.rust-lang.org/cargo/reference/features.html) the target needs in
order to be built. If any of the required features are not enabled, the
target will be skipped. This is only relevant for the `[[bin]]`, `[[bench]]`,
`[[test]]`, and `[[example]]` sections, it has no effect on `[lib]`.

```toml
[features]
# ...
postgres = []
sqlite = []
tools = []

[[bin]]
name = "my-pg-tool"
required-features = ["postgres", "tools"]
```

The `test` field indicates whether or not the target is tested by default by
[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html). The default is `true` for lib, bins, and tests.

> **Note**: Examples are built by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by default to ensure they
> continue to compile, but they are not *tested* by default. Setting `test =
> true` for an example will also build it as a test and run any
> [`#[test]`](https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute) functions defined in the example.

Workspace

The `[workspace]` table in `Cargo.toml` defines which packages are members of
the workspace:

```toml
[workspace]
members = ["member1", "path/to/member2", "crates/*"]
exclude = ["crates/foo", "path/to/other"]
```

An empty `[workspace]` table can be used with a `[package]` to conveniently
create a workspace with the package and all of its path dependencies.

All [`path` dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies) residing in the workspace directory automatically
become members. Additional members can be listed with the `members` key, which
should be an array of strings containing directories with `Cargo.toml` files.

The `members` list also supports [globs](https://docs.rs/glob/0.3.0/glob/struct.Pattern.html) to match multiple paths, using
typical filename glob patterns like `*` and `?`.

The `exclude` key can be used to prevent paths from being included in a
workspace. This can be useful if some path dependencies aren't desired to be
in the workspace at all, or using a glob pattern and you want to remove a
directory.

An empty `[workspace]` table can be used with a `[package]` to conveniently
create a workspace with the package and all of its path dependencies.

All [`path` dependencies] residing in the workspace directory automatically
become members. Additional members can be listed with the `members` key, which
should be an array of strings containing directories with `Cargo.toml` files.

The `members` list also supports [globs] to match multiple paths, using
typical filename glob patterns like `*` and `?`.

The `exclude` key can be used to prevent paths from being included in a
workspace. This can be useful if some path dependencies aren't desired to be
in the workspace at all, or using a glob pattern and you want to remove a
directory.

The optional `default-members` key can be specified to set the members to
operate on when in the workspace root and the package selection flags are not
used:

```toml
[workspace]
members = ["path/to/member1", "path/to/member2", "path/to/member3/*"]
default-members = ["path/to/member2", "path/to/member3/foo"]
```

When specified, `default-members` must expand to a subset of `members`.

The `workspace.package` table is where you define keys that can be
inherited by members of a workspace. These keys can be inherited by
defining them in the member package with `{key}.workspace = true`.

Keys that are supported:

|                |                 |
|----------------|-----------------|
| `authors`      | `categories`    |
| `description`  | `documentation` |
| `edition`      | `exclude`       |
| `homepage`     | `include`       |
| `keywords`     | `license`       |
| `license-file` | `publish`       |
| `readme`       | `repository`    |
| `rust-version` | `version`       |

- `license-file` and `readme` are relative to the workspace root
- `include` and `exclude` are relative to your package root

Example:
```toml
# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.package]
version = "1.2.3"
authors = ["Nice Folks"]
description = "A short description of my package"
documentation = "https://example.com/bar"
```

```toml
# [PROJECT_DIR]/bar/Cargo.toml
[package]
name = "bar"
version.workspace = true
authors.workspace = true
description.workspace = true
documentation.workspace = true
```

The `workspace.dependencies` table is where you define dependencies to be
inherited by members of a workspace.

Specifying a workspace dependency is similar to [package dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) except:
- Dependencies from this table cannot be declared as `optional`
- [`features`][features] declared in this table are additive with the `features` from `[dependencies]`

You can then [inherit the workspace dependency as a package dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace)

Example:
```toml
# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.dependencies]
cc = "1.0.73"
rand = "0.8.5"
regex = { version = "1.6.0", default-features = false, features = ["std"] }
```

```toml
# [PROJECT_DIR]/bar/Cargo.toml
[package]
name = "bar"
version = "0.2.0"

[dependencies]
regex = { workspace = true, features = ["unicode"] }

[build-dependencies]
cc.workspace = true

[dev-dependencies]
rand.workspace = true
```

The `workspace.lints` table is where you define lint configuration to be inherited by members of a workspace.

The `workspace.metadata` table is ignored by Cargo and will not be warned
about. This section can be used for tools that would like to store workspace
configuration in `Cargo.toml`. For example:

```toml
[workspace]
members = ["member1", "member2"]

[workspace.metadata.webcontents]
root = "path/to/webproject"
tool = ["npm", "run", "build"]
# ...
```

There is a similar set of tables at the package level at
`package.metadata`. While cargo does not specify a
format for the content of either of these tables, it is suggested that
external tools may wish to use them in a consistent fashion, such as referring
to the data in `workspace.metadata` if data is missing from `package.metadata`,
if that makes sense for the tool in question.

Authors

Categories

The `categories` field is an array of strings of the categories this package
belongs to.

```toml
categories = ["command-line-utilities", "development-tools::cargo-plugins"]
```

> **Note**: [crates.io](https://crates.io) has a maximum of 5 categories. Each category should
> match one of the strings available at https://crates.io/category_slugs, and
> must match exactly.

Description

The description is a short blurb about the package. [crates.io](https://crates.io) will display
this with your package. This should be plain text (not Markdown).

```toml
[package]
# ...
description = "A short description of my package"
```

> **Note**: [crates.io](https://crates.io) requires the `description` to be set.

Documentation

The `documentation` field specifies a URL to a website hosting the crate's
documentation. If no URL is specified in the manifest file, [crates.io](https://crates.io) will
automatically link your crate to the corresponding [docs.rs](https://docs.rs) page.

```toml
[package]
# ...
documentation = "https://docs.rs/bitflags"
```

Exclude

Homepage

The `homepage` field should be a URL to a site that is the home page for your
package.

```toml
[package]
# ...
homepage = "https://serde.rs/"
```

Keywords

License

LicenseFile

The `license-file` field contains the path to a file
containing the text of the license (relative to this `Cargo.toml`).

```toml
[package]
# ...
license-file = "LICENSE.txt"
```

> **Note**: [crates.io](https://crates.io) requires either `license` or `license-file` to be set.

Repository

The `repository` field should be a URL to the source repository for your
package.

```toml
[package]
# ...
repository = "https://github.com/rust-lang/cargo/"
```

RustVersion

Workspace

The `workspace` field allow keys to be inherited by defining them in the member package with `{key}.workspace = true`

Playdate Package Metadata

Metadata and build configuration.

A unique identifier for your game, in reverse DNS notation.

A game version number, formatted any way you wish, that is displayed to players. It is not used to compute when updates should occur.

A monotonically-increasing integer value used to indicate a unique version of your game. This can be set using an automated build process like Continuous Integration to avoid having to set the value by hand.

For sideloaded games, buildNumber is required and is used to determine when a newer version is available to download.

A directory of images that will be used by the launcher.

More in [official documentation](https://sdk.play.date/#pdxinfo).

Should point to the path of a short audio file to be played as the game launch animation is taking place.

More in [official documentation](https://sdk.play.date/#pdxinfo).

Optional. A content warning that displays when the user launches your game for the first time. The user will have the option of backing out and not launching your game if they choose.

Optional. A second content warning that displays on a second screen when the user launches your game for the first time. The user will have the option of backing out and not launching your game if they choose.

Note: `content-warning2` will only display if a `content-warning` attribute is also specified.

The string displayed on the content warning screen can only be so long before it will be truncated with an "…" character. Be sure to keep this in mind when designing your `content-warning` and `content-warning2` text.

bundle-id name description author image-path launch-sound-path

Assets list

List of paths to include.

Path

Path to include.

Assets rules

Rules used to resolve paths to include.

Path

Path of files to include. Can be absolute, relative to the crate root, or/and glob.

Left hand is where to put files, path in the resulting package.

Right hand is a path or pattern to match files to include.

Include

Include or exclude the file or glob-pattern.

Assets Configuration

Options for assets paths resolution and how to build assets collection

Allow overwriting existing files.

Allow build assets for dependencies.

Configuration

Package build options.

A schema for Cargo.toml.

[project] is deprecated. Use [package] instead.

The library target defines a "library" that can be used and linked by other
libraries and executables. The filename defaults to `src/lib.rs`, and the name
of the library defaults to the name of the package. A package can have only
one library. The settings for the library can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[lib]`
table in `Cargo.toml`.

```toml
# Example of customizing the library in Cargo.toml.
[lib]
crate-type = ["cdylib"]
bench = false
```

Binary targets are executable programs that can be run after being compiled.
The default binary filename is `src/main.rs`, which defaults to the name of
the package. Additional binaries are stored in the [`src/bin/`
directory](https://doc.rust-lang.org/cargo/guide/project-layout.html). The settings for each binary can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[[bin]]` tables in `Cargo.toml`.

Binaries can use the public API of the package's library. They are also linked
with the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) defined in `Cargo.toml`.

You can run individual binaries with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with the `--bin
<bin-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html) can be used to copy the executable to a
common location.

```toml
# Example of customizing binaries in Cargo.toml.
[[bin]]
name = "cool-tool"
test = false
bench = false

[[bin]]
name = "frobnicator"
required-features = ["frobnicate"]
```

Files located under the [examples directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are example uses of the functionality provided by the library. When compiled, they are placed in the[ target/debug/examples directory](https://doc.rust-lang.org/cargo/guide/build-cache.html).

Examples can use the public API of the package's library. They are also linked with the [dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in Cargo.toml.

By default, examples are executable binaries (with a `main()` function). You
can specify the [`crate-type` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-crate-type-field) to make an example
be compiled as a library:

```toml
[[example]]
name = "foo"
crate-type = ["staticlib"]
```

You can run individual executable examples with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with
the `--example <example-name>` option. Library examples can be built with
[`cargo build`](https://doc.rust-lang.org/cargo/commands/cargo-build.html) with the `--example <example-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html)
with the `--example <example-name>` option can be used to copy executable
binaries to a common location. Examples are compiled by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by
default to protect them from bit-rotting. Set [the `test`
field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-test-field) to `true` if you have `#[test]` functions in the
example that you want to run with [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html).

Files located under the [`tests` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are integration
tests. When you run [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html), Cargo will compile each of these files as
a separate crate, and execute them.

Integration tests can use the public API of the package's library. They are
also linked with the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and
[`[dev-dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in `Cargo.toml`.

If you want to share code among multiple integration tests, you can place it
in a separate module such as `tests/common/mod.rs` and then put `mod common;`
in each test to import it.

Each integration test results in a separate executable binary, and [`cargo
test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) will run them serially. In some cases this can be inefficient, as it
can take longer to compile, and may not make full use of multiple CPUs when
running the tests. If you have a lot of integration tests, you may want to
consider creating a single integration test, and split the tests into multiple
modules. The libtest harness will automatically find all of the `#[test]`
annotated functions and run them in parallel. You can pass module names to
[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) to only run the tests within that module.

Binary targets are automatically built if there is an integration test. This
allows an integration test to execute the binary to exercise and test its
behavior. The `CARGO_BIN_EXE_<name>` [environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) is set when the
integration test is built so that it can use the [`env` macro](https://doc.rust-lang.org/std/macro.env.html) to locate the
executable.

Benchmarks provide a way to test the performance of your code using the
[`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html) command. They follow the same structure as [tests](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#tests),
with each benchmark function annotated with the `#[bench]` attribute.
Similarly to tests:

* Benchmarks are placed in the [`benches` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html).
* Benchmark functions defined in libraries and binaries have access to the
  *private* API within the target they are defined in. Benchmarks in the
  `benches` directory may use the *public* API.
* [The `bench` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-bench-field) can be used to define which targets
  are benchmarked by default.
* [The `harness` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-harness-field) can be used to disable the
  built-in harness.

> **Note**: The [`#[bench]`
> attribute](https://doc.rust-lang.org/unstable-book/library-features/test.html) is currently
> unstable and only available on the [nightly channel](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html). There are some
> packages available on [crates.io](https://crates.io/keywords/benchmark) that
> may help with running benchmarks on the stable channel, such as
> [Criterion](https://crates.io/crates/criterion).

[dev_dependencies] is deprecated. Use [dev-dependencies] instead.

[build_dependencies] is deprecated. Use [build-dependencies] instead.

[crates.io](https://crates.io) can display various badges for build status, test coverage, etc. for
each crate. All badges are optional.

- The badges pertaining to build status that are currently available are
  Appveyor, CircleCI, Cirrus CI, GitLab, Azure DevOps, Travis CI and Bitbucket
  Pipelines.
- Available badges pertaining to code test coverage are Codecov and Coveralls.
- There are also maintenance-related badges based on isitmaintained.com
  which state the issue resolution time, percent of open issues, and future
  maintenance intentions.

Most badge specifications require a `repository` key. It is expected to be in
`user/repo` format.

```toml
[badges]

# Appveyor: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default), `bitbucket`, and
# `gitlab`; `id` is optional; you can specify the appveyor project id if you
# want to use that instead. `project_name` is optional; use when the repository
# name differs from the appveyor project name.
appveyor = { repository = "...", branch = "master", service = "github" }

# Circle CI: `repository` is required. `branch` is optional; default is `master`
circle-ci = { repository = "...", branch = "master" }

# Cirrus CI: `repository` is required. `branch` is optional; default is `master`
cirrus-ci = { repository = "...", branch = "master" }

# GitLab: `repository` is required. `branch` is optional; default is `master`
gitlab = { repository = "...", branch = "master" }

# Azure DevOps: `project` is required. `pipeline` is required. `build` is optional; default is `1`
# Note: project = `organization/project`, pipeline = `name_of_pipeline`, build = `definitionId`
azure-devops = { project = "...", pipeline = "...", build="2" }

# Travis CI: `repository` in format "<user>/<project>" is required.
# `branch` is optional; default is `master`
travis-ci = { repository = "...", branch = "master" }

# Bitbucket Pipelines: `repository` is required. `branch` is required
bitbucket-pipelines = { repository = "...", branch = "master" }

# Codecov: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default), `bitbucket`, and
# `gitlab`.
codecov = { repository = "...", branch = "master", service = "github" }

# Coveralls: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default) and `bitbucket`.
coveralls = { repository = "...", branch = "master", service = "github" }

# Is it maintained resolution time: `repository` is required.
is-it-maintained-issue-resolution = { repository = "..." }

# Is it maintained percentage of open issues: `repository` is required.
is-it-maintained-open-issues = { repository = "..." }

# Maintenance: `status` is required. Available options are:
# - `actively-developed`: New features are being added and bugs are being fixed.
# - `passively-maintained`: There are no plans for new features, but the maintainer intends to
#   respond to issues that get filed.
# - `as-is`: The crate is feature complete, the maintainer does not intend to continue working on
#   it or providing support, but it works for the purposes it was designed for.
# - `experimental`: The author wants to share it with the community but is not intending to meet
#   anyone's particular use case.
# - `looking-for-maintainer`: The current maintainer would like to transfer the crate to someone
#   else.
# - `deprecated`: The maintainer does not recommend using this crate (the description of the crate
#   can describe why, there could be a better solution available or there could be problems with
#   the crate that the author does not want to fix).
# - `none`: Displays no badge on crates.io, since the maintainer has not chosen to specify
#   their intentions, potential crate users will need to investigate on their own.
maintenance = { status = "..." }
```

Cargo supports features to allow expression of:

* conditional compilation options (usable through `cfg` attributes);
* optional dependencies, which enhance a package, but are not required; and
* clusters of optional dependencies, such as `postgres-all`, that would include the
  `postgres` package, the `postgres-macros` package, and possibly other packages
  (such as development-time mocking libraries, debugging tools, etc.).

A feature of a package is either an optional dependency, or a set of other
features.

Override the default level of lints from different tools by assigning them to a new level in a table.

Inherit lints from the workspace manifest.

The `[patch]` section of `Cargo.toml` can be used to override dependencies
with other copies. The syntax is similar to the
[`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) section.

Cargo.toml

Provide a JSON object that satisfies the schema "Cargo.toml". Here are the required top‑level fields: none (all optional). Return only the valid JSON object.