FutureIncompatibilityReason in rustc_lint_defs - Rust (original) (raw)

Enum FutureIncompatibilityReason

Source 

pub enum FutureIncompatibilityReason {
    FutureReleaseErrorDontReportInDeps,
    FutureReleaseErrorReportInDeps,
    FutureReleaseSemanticsChange,
    EditionError(Edition),
    EditionSemanticsChange(Edition),
    EditionAndFutureReleaseError(Edition),
    EditionAndFutureReleaseSemanticsChange(Edition),
    Custom(&'static str),
}

Expand description

§

This will be an error in a future release for all editions

This will not show up in cargo’s future breakage report. The warning will hence only be seen in local crates, not in dependencies.

Choose this variant when you are first introducing a “future incompatible” warning that is intended to eventually be fixed in the future. This allows crate developers an opportunity to fix the warning before blasting all dependents with a warning they can’t fix (dependents have to wait for a new release of the affected crate to be published).

After a lint has been in this state for a while, consider graduating it to FutureIncompatibilityReason::FutureReleaseErrorReportInDeps.

§

This will be an error in a future release, and Cargo should create a report even for dependencies

This is the only reason that will make future incompatibility warnings show up in cargo’s reports. All other future incompatibility warnings are not visible when they occur in a dependency.

Choose this variant after the lint has been sitting in theFutureIncompatibilityReason::FutureReleaseErrorDontReportInDepsstate for a while, and you feel like it is ready to graduate to warning everyone. It is a good signal that it is ready if you can determine that all or most affected crates on crates.io have been updated.

After some period of time, lints with this variant can be turned into hard errors (and the lint removed). Preferably when there is some confidence that the number of impacted projects is very small (few should have a broken dependency in their dependency tree).

§

§

Previously accepted code that will become an error in the provided edition

Choose this variant for code that you want to start rejecting across an edition boundary. This will automatically include the lint in therust-20xx-compatibility lint group, which is used by cargo fix --edition to do migrations. The lint should be auto-fixable withApplicability::MachineApplicable.

The lint can either be Allow or Warn by default. If it is Allow, users usually won’t see this warning unless they are doing an edition migration manually or there is a problem during the migration (cargo’s automatic migrations will force the level to Warn). If it is Warnby default, users on all editions will see this warning (only do this if you think it is important for everyone to be aware of the change, and to encourage people to update their code on all editions).

See also FutureIncompatibilityReason::EditionSemanticsChange if you have code that is changing semantics across the edition (as opposed to being rejected).

§

Code that changes meaning in some way in the provided edition

This is the same as FutureIncompatibilityReason::EditionError, except for situations where the semantics change across an edition. It slightly changes the text of the diagnostic, but is otherwise the same.

§

This will be an error in the provided edition and in a future release.

This variant a combination of FutureReleaseErrorDontReportInDepsand EditionError. This is useful in rare cases when we want to have “preview” of a breaking change in an edition, but do a breaking change later on all editions anyway.

§

This will change meaning in the provided edition and in a future release.

This variant a combination of FutureReleaseSemanticsChangeand EditionSemanticsChange. This is useful in rare cases when we want to have “preview” of a breaking change in an edition, but do a breaking change later on all editions anyway.

§

§

§

§

§

§

§

§

§

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 24 bytes

Size for each variant: