-
Notifications
You must be signed in to change notification settings - Fork 26
Make expect_eq and friends more hygienic
#475
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
Conversation
Currently, `expect_that!` doesn't work unless both `verify_eq!` and `verify_that` are in scope. This is okay or users of the prelude, but not for those who don't. I've noticed that googletest-rust has a number of other macro hygiene issue, but to avoid making an overly large PR, I'll address them as I come across them.
related google#475 I went for using fully qualified method names, rather than `use $crate::GoogleTestSupport as _;` since it's more hygienic. `use $crate::GoogleTestSupport as _;` can cause issues, resulting in a conflict, if the user introduces another method with the same name as one on `GoogleTestSupport`
related google#475 I went for using fully qualified method names, rather than `use $crate::GoogleTestSupport as _;` since it's more hygienic. `use $crate::GoogleTestSupport as _;` can cause issues, resulting in a conflict, if the user introduces another method with the same name as one on `GoogleTestSupport`
This requires extra imports because googletest macros look for items in the local scope. I've opened a PR to fix this google/googletest-rust#475 Once that is released, the extra imports will become unused.
This requires extra imports because googletest macros look for items in the local scope. I've opened a PR to fix this google/googletest-rust#475 Once that is released, the extra imports will become unused.
|
Thank you for the PR! Unfortunately it fell through the cracks and we didn't notice it. In the meantime other contributors have submitted similar fixes as well as the |
related google#475 I went for using fully qualified method names, rather than `use $crate::GoogleTestSupport as _;` since it's more hygienic. `use $crate::GoogleTestSupport as _;` can cause issues, resulting in a conflict, if the user introduces another method with the same name as one on `GoogleTestSupport`
related google#475 I went for using fully qualified method names, rather than `use $crate::GoogleTestSupport as _;` since it's more hygienic. `use $crate::GoogleTestSupport as _;` can cause issues, resulting in a conflict, if the user introduces another method with the same name as one on `GoogleTestSupport`
related google#475 I went for using fully qualified method names, rather than `use $crate::GoogleTestSupport as _;` since it's more hygienic. `use $crate::GoogleTestSupport as _;` can cause issues, resulting in a conflict, if the user introduces another method with the same name as one on `GoogleTestSupport`
related google#475 I went for using fully qualified method names, rather than `use $crate::GoogleTestSupport as _;` since it's more hygienic. `use $crate::GoogleTestSupport as _;` can cause issues, resulting in a conflict, if the user introduces another method with the same name as one on `GoogleTestSupport`
No worries. It's great to see the hygiene has improved since :) |
Thanks for googletest-rust. It's been awesome to use 🙌
Currently,
expect_that!doesn't work unless bothverify_eq!andverify_thatare in scope.This is okay or users of the prelude, but not for those who don't.
I've noticed that googletest-rust has a number of other macro hygiene issues, but to avoid making an overly large PR, I'll address them as I come across them.