Skip to content

Adding #[derive()] changes blob import semantics #115377

Closed
@danielhenrymantilla

Description

@danielhenrymantilla

image

I tried this code:

use module::*;
mod module {
    pub enum B {}
    impl B { pub const ASSOC: bool = true; } // used to distinguish the `B`s
}

#[derive()]
pub enum B {}
impl B { pub const ASSOC: bool = false; }

fn main() {
    let it = {
        use self::*;
        B::ASSOC
    };
    assert_eq!(
        it,
        {
            use self::*;
            B::ASSOC
        },
    );
}

I expected to see this happen: the assertion passing, since { use self::*; B::ASSOC } should have a consistent value/meaning within main's fn body where no other items are defined.

Instead, this happened: the assertion fails!

Meta

This regressed in 1.52.0

Extra comments

  • The key element playing a role here, beyond the blob imports, is the #[derive()] slapped onto B. This seems to allow for the blob-imported module::B to somehow gain priority over the clearly-defined crate::B type within fn main's blob import.

  • I did not expect the "moving of { use self::*; B::ASSOC } block" to alter this quirk (I was initially writing the MRE as assert_eq!(B::ASSSOC, { use … }) when I ran into this extra bug).

  • Could resolve: Remove artificial import ambiguity errors #112086 be relevant? cc @petrochenkov

  • Initially discovered on Discord by user @kyuuhachi

@rustbot modify labels: +regression-from-stable-to-stable

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.P-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions