FuelLabs/sway · error

failed to parse manifest: {}.

Error message

failed to parse manifest: {}.

What it means

Thrown by PackageManifestFile::from_string when the contents of a package-level Forc.toml cannot be deserialized into a PackageManifest with toml::de::Deserializer + serde_ignored. The {} is the underlying toml/serde error and includes the exact line/column and the expected vs found type. It fires on invalid TOML syntax or on values that do not match the manifest schema (wrong type, missing required field, wrong table shape). Note that merely unknown keys do NOT trigger this (they only produce 'unused manifest key' warnings); a parse error means structure/type problems.

Source

Thrown at forc-pkg/src/manifest/mod.rs:691

    /// Given a path to a `Forc.toml`, read it and construct a `PackageManifest`.
    ///
    /// This also `validate`s the manifest, returning an `Err` in the case that invalid names,
    /// fields were used.
    ///
    /// If `std` is unspecified, `std` will be added to the `dependencies` table
    /// implicitly. In this case, the git tag associated with the version of this crate is used to
    /// specify the pinned commit at which we fetch `std`.
    pub fn from_string(contents: String) -> Result<Self> {
        // While creating a `ManifestFile` we need to check if the given path corresponds to a
        // package or a workspace. While doing so, we should be printing the warnings if the given
        // file parses so that we only see warnings for the correct type of manifest.
        let mut warnings = vec![];
        let toml_de = toml::de::Deserializer::new(&contents);
        let mut manifest: Self = serde_ignored::deserialize(toml_de, |path| {
            let warning = format!("unused manifest key: {path}");
            warnings.push(warning);
        })
        .map_err(|e| anyhow!("failed to parse manifest: {}.", e))?;
        for warning in warnings {
            println_warning(&warning);
        }
        manifest.implicitly_include_std_if_missing();
        manifest.implicitly_include_default_build_profiles_if_missing();
        manifest.validate()?;
        Ok(manifest)
    }

    /// Validate the `PackageManifest`.
    ///
    /// This checks:
    /// 1. The project and organization names against a set of reserved/restricted keywords and patterns.
    /// 2. The validity of the details provided. Makes sure that there are no mismatching detail
    ///    declarations (to prevent mixing details specific to certain types).
    /// 3. The dependencies listed does not have an alias ("package" field) that is the same as package name.
    pub fn validate(&self) -> Result<()> {
        validate_project_name(&self.project.name)?;

View on GitHub (pinned to 47e5e902fa)

Solutions

1. Read the serde error: it names the offending key with line/column - fix that exact spot first.
2. Verify the file is syntactically valid TOML (e.g. taplo lint or toml::from_str::<toml::Value>) before blaming schema fields.
3. Check field types against the forc manifest docs for your forc version (name/entry/authors are strings, dependencies are tables).
4. If unsure, scaffold with 'forc init' and re-apply your changes incrementally until the error reappears.

Example fix

# Forc.toml - before (name is not a string)
[project]
name = 123
entry = "main.sw"

# after
[project]
name = "my_contract"
entry = "main.sw"

fn precheck_manifest(contents: &str) -> Result<(), String> {
    let v: toml::Value = toml::from_str(contents).map_err(|e| format!("invalid TOML: {e}"))?;
    let name = v.get("project").and_then(|p| p.get("name")).and_then(|n| n.as_str());
    if name.is_none() {
        return Err("[project] table missing or 'name' is not a string".into());
    }
    Ok(())
}
// run before PackageManifestFile::from_string

match PackageManifestFile::from_string(contents) {
    Ok(m) => { /* ... */ }
    Err(e) => eprintln!("Forc.toml is invalid; fix the reported line/column: {e:#}"),
}

When it happens

Trigger: Calling PackageManifestFile::from_string(contents) (or forc CLI loading a package Forc.toml) where: [project] name = 123 (string expected), the [project] table is missing entirely, a dependency entry uses a field type the schema rejects (e.g. git = true), duplicate TOML keys exist, or a bracket/inline-table is malformed.

Common situations: Hand-editing Forc.toml and introducing a typo; copy-pasting a dependency block from docs of a different forc version; writing YAML-style syntax into a TOML file; using [package] instead of [project]; a merge conflict resolution that leaves broken TOML.

Understand the failure class

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• Invalid revert code for test \"{}\". A revert code must be a
• failed to parse dependency "{}": {}
• missing closing parenthesis
• missing pkg string
• invalid salt in lock file: {e}

AI-assisted analysis of FuelLabs/sway@47e5e902fa (2026-08-16). Data as JSON: /api/errors/df772022e556a991. Report an issue: GitHub.