Skip to content

portability risk: impls for libstd type can be platform dependent #22228

@pnkfelix

Description

@pnkfelix

Our cfg system makes it a bit too easy for a given type to implement a given libstd trait on one platform and not implement that trait on a different platform. This risk is especially high for default impls, where a negative impl may be present for a field of a given abstraction but not on another.

According to this reddit post, this problem manifested itself for the Process type, which was/is Send on non-windows platforms but is not Send on windows, due to the use of a *mut () field in the windows version.

Now, the obvious answer here is "testing!" But we might want to try to go further.

E.g., we could implement an analysis that pulls in the libstd code under every target cfg, and then compares all of the pub types to ensure that they are all consistent with respect to which pub traits they implement.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-testsuiteArea: The testsuite used to check the correctness of rustcP-mediumMedium priority

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions