-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Bug in generic trait implementation? #3744
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Not sure what the bug is here? But maybe I'm misunderstanding? |
The In contrast, it requires an explicit |
Sorry, I didn't read your code correctly at first. Are you saying that if you comment out the line in |
Yes :) |
Okay, weird; I'll try to reproduce when I get a moment. |
This actually works as intended; you just need to It still seems a little weird to me, though. Maybe @pcwalton could comment? |
I'm just going to close this since I think it's intended behavior. If you think it should change, feel free to file an RFC bug :-) |
I actually didn't think that was the intended behavior. I thought you had to import traits to invoke trait methods, and I didn't think it was relevant where the impl for the trait appeared. @pcwalton is this incorrect? |
Seems like this is expected. Closing. |
Add `O_NOFOLLOW` flag support
There is a possible bug when you define a generic trait implementation within a different module but within the same file, e.g. given:
The compiler errors with:
If, however, you put a
use crypto::*;
statement before themain()
, then everything seems to work. This behaviour feels like a bug sinceblock_size()
works andhexdigest()
is defined within the same module...The text was updated successfully, but these errors were encountered: