FuelLabs/sway · error · anyhow::Error

{err}

Error message

{err}

What it means

Before compiling a package, forc reconciles the [experimental] table of its Forc.toml with the --experimental/--no-experimental CLI options via ExperimentalFeatures::new. Conflicting or unknown input (a feature enabled in the manifest but disabled on the CLI, or a feature name this forc version does not recognize) returns an error that pkg.rs wraps and rethrows verbatim.

Source

Thrown at forc-pkg/src/pkg.rs:2456

        let manifest = &plan.manifest_map()[&pkg.id()];
        let program_ty = manifest.program_type().ok();
        let dbg_generation = match (profile.is_release(), manifest.project.force_dbg_in_release) {
            (true, Some(true)) | (false, _) => DbgGeneration::Full,
            (true, _) => DbgGeneration::None,
        };

        print_compiling(
            program_ty.as_ref(),
            &pkg.name,
            &pkg.source.display_compiling(manifest.dir()),
        );

        let experimental = ExperimentalFeatures::new(
            &manifest.project.experimental,
            experimental,
            no_experimental,
        )
        .map_err(|err| anyhow!("{err}"))?;

        let descriptor = PackageDescriptor {
            name: pkg.name.clone(),
            target,
            pinned: pkg.clone(),
            manifest_file: manifest.clone(),
        };

        let fail = |infos, warnings, errors| {
            print_on_failure(
                engines.se(),
                profile.terse,
                infos,
                warnings,
                errors,
                profile.reverse_results,
            );
            bail!("Failed to compile {}", pkg.name);

View on GitHub (pinned to 47e5e902fa)

Solutions

1. Make manifest and CLI agree: remove the conflicting flag or flip the [experimental] entry
2. Check the feature name against the current forc release notes and fix spelling/case
3. Choose a single source of truth: control features only via the manifest or only via CLI flags

Example fix

# before: Forc.toml has [experimental] new_encoding = false
# and you run: forc build --experimental new_encoding

# after (pick one source of truth)
# Forc.toml: new_encoding = true, no CLI flag

// illustrative: detect manifest/CLI conflicts before calling build
fn experimental_conflict(
    manifest_keys: &[String],
    cli_enable: &[String],
    cli_disable: &[String],
) -> bool {
    manifest_keys.iter().any(|k| cli_disable.iter().any(|d| d == k))
        || cli_enable.iter().any(|f| cli_disable.contains(f))
}
// if experimental_conflict(&toml.experimental_keys(), &opts.experimental, &opts.no_experimental) {
//     bail!("conflicting experimental feature flags");
// }

When it happens

Trigger: Running forc build while Forc.toml contains [experimental] entries that contradict the CLI flags (e.g. new_encoding = false plus --experimental new_encoding), or listing a feature name unknown to the installed toolchain.

Common situations: CI pipelines applying global experimental flags over projects that pin their own experimental set; upgrading forc where an experimental feature was renamed or removed; copy-pasting feature names from changelogs.

Related errors

• dependency of {:?} named {:?} is invalid: {}
• Cannot found project node in the graph
• Couldn't find member manifest for {}
• Failed to run forc plugins
• Source file was modified, and the mapping is now out of rang

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