Skip to main content

native_strict_only_error

Function native_strict_only_error 

Source
pub fn native_strict_only_error(
    file: FileId,
    explicit_types: Option<TypePolicy>,
) -> Option<Diagnostic>
Expand description

The B0.9 native strict-only enforcement point (docs/b0-sequencing.md §B0.9’s “the strict-only ruling’s enforcement point”, issue #1342; decision-log 2026-07-19 “Typing posture ruled”: “the native surface is strict-only — types = strict is a property of the dialect, not a project knob; gradual typing does not exist on the native surface”).

The inverse of [config_error] above in spirit — both are project-level types config errors with no single offending span — but a different axis: [config_error] rejects types = strict under the wrong dialect (an ink-only concept); this rejects an explicit types = gradual knob reaching a native (.brink) file, which has no dialect at all (Language::Native is a separate, path-derived classification — see brink-db’s file_language doc). Deliberately keyed on the explicit AnalysisOptions::types field, never the dialect-defaulted [AnalysisOptions::type_policy] result: a native project that never touches the types knob resolves through the ink-shaped resolve_type_policy default (which native’s B0.10 dialect wiring has not yet overridden) and must not be penalized for a default it never chose — only a caller (CLI flag, brink.toml, editor/API call) that explicitly dials types = gradual for a native file hits this.

None when explicit_types isn’t Some(TypePolicy::Gradual) (unset, or explicitly Strict) — the only two cases a native compile passes this gate.