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

DCA issue when traits are define in library and used in generic function #3671

Closed
esdrubal opened this issue Jan 2, 2023 · 0 comments · Fixed by #3878
Closed

DCA issue when traits are define in library and used in generic function #3671

esdrubal opened this issue Jan 2, 2023 · 0 comments · Fixed by #3878
Assignees
Labels
compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen

Comments

@esdrubal
Copy link
Contributor

esdrubal commented Jan 2, 2023

When traits are define in library and used in main.sw within a generic function we get a This declaration is never used for the trait implementation that is used.

main.sw

script;

dep traits;

use std::assert::assert;
use traits::*;

fn test_my_eq<T>(x: T, y: T) -> bool where T: MyEq {
  x.my_eq(y)
}

fn main() {
  assert(test_my_eq(42, 42));
}

traits.sw

library traits;

pub trait MyEq {
    fn my_eq(self, other: Self) -> bool;
}

impl MyEq for u64 {
    fn my_eq(self, other: Self) -> bool {
        self == other
    }
}
warning
      --> /home/iota/sway/test/src/e2e_vm_tests/test_programs/should_pass/language/trait_dep/src/traits.sw:3:11
       |
     1 | 
     2 | 
     3 | pub trait MyEq {
       |           ---- This trait is never implemented.
     4 |     fn my_eq(self, other: Self) -> bool;
     5 | }
       |
     ____

     warning
       --> /home/iota/sway/test/src/e2e_vm_tests/test_programs/should_pass/language/trait_dep/src/traits.sw:7:1
        |
      5 |   
      6 |   
      7 | / impl MyEq for u64 {
      8 | |     fn my_eq(self, other: Self) -> bool {
      9 | |         self == other
     10 | |     }
     11 | | }
        | |_- This declaration is never used.
        |
     ____
@tritao tritao added bug Something isn't working compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen labels Jan 2, 2023
@tritao tritao self-assigned this Jan 2, 2023
@mohammadfawaz mohammadfawaz removed the bug Something isn't working label Jan 2, 2023
tritao added a commit to tritao/sway that referenced this issue Jan 24, 2023
tritao added a commit to tritao/sway that referenced this issue Feb 1, 2023
tritao added a commit to tritao/sway that referenced this issue Feb 1, 2023
tritao added a commit to tritao/sway that referenced this issue Feb 1, 2023
tritao added a commit to tritao/sway that referenced this issue Feb 1, 2023
tritao added a commit to tritao/sway that referenced this issue Feb 6, 2023
tritao added a commit to tritao/sway that referenced this issue Feb 6, 2023
tritao added a commit that referenced this issue Feb 7, 2023
Closes #3671.

There were a bunch of different fixes necessary to fix this one, which
are separated into individual commits to make it easier to review. The
main gist is that the DCA now keeps track of functions by their
signature instead of just their name and when encountering monomorphized
functions in the DCA engine, we now look for their counterpart fully
generic version and link the two together.

Previously:


![bug](https://user-images.githubusercontent.com/602268/216972881-65b9a7c3-083e-44ff-9a5b-cc310bb19146.png)

Now:


![bug3](https://user-images.githubusercontent.com/602268/216972937-c6be0909-9349-4fd4-9d33-f9dcaca93767.png)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants