Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with trait resolution when local traits shadow glob imported ones #5700

Open
ironcev opened this issue Mar 6, 2024 · 1 comment
Open
Assignees
Labels
bug Something isn't working compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler General compiler. Should eventually become more specific as the issue is triaged

Comments

@ironcev
Copy link
Member

ironcev commented Mar 6, 2024

We have several issues in trait resolution when there are local traits shadowing glob imported ones (from the prelude or own libs, both). I am listing all the issues here using the Shift trait from the prelude (core::ops::Shift) and own libs as example.

Local trait with same trait items as glob imported

If the local trait has exactly the same items like the glob imported trait, the error will be emitted, that the trait is already implemented where the implementation is one coming from the core::ops in this case.

script;

// Trait exactly the same like the glob imported.
// It should shadow the glob imported one from the prelude.
trait Shift {
    fn lsh(self, other: u64) -> Self;
    fn rsh(self, other: u64) -> Self;
}

// This should be implementing the above trait and no error should be emitted but it is.
impl Shift for u64 {
    fn lsh(self, other: u64) -> Self {
        asm(r1 : self, r2: other, r3) {
            sll r3 r1 r2;
            r3: u64
        }
    }

    fn rsh(self, other: u64) -> Self {
        asm(r1 : self, r2: other, r3) {
            srl r3 r1 r2;
            r3: u64
        }
    }
}

fn main() -> u64 {
  100 << 2
}

Local trait with different trait items as glob imported

Interestingly, if the local trait has different trait items as the glob imported one, it looks like the local one get's picked in the resolution, because the errors emitted are pointing to missing implementation of items, and implementing non-existing items.

script;

// Local trait with different items.
trait Shift {
    fn function(self) -> u64;
}

// We are wrongly implementing items that are not in the local trait.
impl Shift for u64 {
    fn lsh(self, other: u64) -> Self {
    ...
    }

    fn rsh(self, other: u64) -> Self {
    ...
    }
}

fn main() -> u64 {
  100 << 2
}

This will emit the following errors, which means that in this case the local Shift was resolved (as it should be):

Function "lsh" is not a part of trait "Shift"'s interface surface.
Function "rsh" is not a part of trait "Shift"'s interface surface.
Functions are missing from this trait implementation: function

Same issues with non-prelude items

E.g., if we have a lib.sw:

library;
pub trait Trait {}
impl Trait for u64 {}

and a main.sw:

script;

mod lib;
use lib::*;

trait Trait {}

// Error gets wrongly emitted here that the trait is already implemented,
// because the lib::Trait gets resolved and not the local one.
impl Trait for u64 {}

fn main() {
}
@ironcev ironcev added bug Something isn't working compiler General compiler. Should eventually become more specific as the issue is triaged compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen labels Mar 6, 2024
@ironcev
Copy link
Member Author

ironcev commented Apr 25, 2024

Related to #5500 and #5599

@xunilrj xunilrj mentioned this issue Apr 25, 2024
28 tasks
@ironcev ironcev assigned ironcev and jjcnn and unassigned ironcev Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler General compiler. Should eventually become more specific as the issue is triaged
Projects
None yet
Development

No branches or pull requests

2 participants