-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Resolve empty statement warning when using PYBIND11_OVERLOAD_PURE_NAME and PYBIND11_OVERLOAD_PURE #2325
Resolve empty statement warning when using PYBIND11_OVERLOAD_PURE_NAME and PYBIND11_OVERLOAD_PURE #2325
Conversation
4e080bd
to
cb51ef4
Compare
do { \ | ||
PYBIND11_OVERLOAD_INT(PYBIND11_TYPE(ret_type), PYBIND11_TYPE(cname), name, __VA_ARGS__); \ | ||
pybind11::pybind11_fail("Tried to call pure virtual function \"" PYBIND11_STRINGIFY(cname) "::" name "\""); \ | ||
} while (false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The prior version of this macro ended with a ;
, could break some users?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, removing these semicolons is the whole point of the PR, cfr. #2166!
But ... even if some user code breaks, in principle, 1. it's a loud breaking change (it won't silently crash, but it'll just complain during compilation), 2. usage is like that in all the docs and tests, so arguably, using the macro without ;
is undocumented behavior.
After a bit of sleep, I think the potential breaking change isn't worth it. The resolution to #2166 could as well be "remove the semicolon in user code". |
What made me remove it (rather than comments "well, then don't put the semicolon"), is that there's also a semicolon in the docs? |
We can change the docs. Also #2166 isn't an error, just a warning raised by turning the |
Duplicate-ish of #2188 |
Ah, I hadn't noticed. Just trying to fix/close some issues. |
As long as we don't violate SemVer (i.e. documented behavior no longer compiling), I am okay with this change. It seems to me that there is no such violation (I only had a brief look though). |
6d32d02
to
ab80ad1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kinds of breaking changes in this PR:
- Moving functions from
pybind11
topybind11::detail
namespace. - Renaming things.
I'm not strictly against these changes, however we need them explicitly enumerated in the upgrade guide.
do { \ | ||
PYBIND11_OVERRIDE_IMPL(PYBIND11_TYPE(ret_type), PYBIND11_TYPE(cname), name, __VA_ARGS__); \ | ||
return cname::fn(__VA_ARGS__); \ | ||
} while (false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that a good change, the
do { ... } while (false)
?
Assuming we want to make this kind of a breaking change, sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that ever going to break something that wasn't broken before, is the main question?
I can only imagine if (...) PYBIND11_OVERRIDE(...);
to actually get fixed, rather than broken?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of users using PYBIND11_OVERLOAD
without a trailing semicolon. However, that's OVERLOAD
, the deprecated macro. Moving on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, yes. I still need to fix that, such that the original macros are the same as they were. That was the whole point of this exercise!
Right, so, I wanted to first still get the docs straight, but Boris is too fast for me :-)
Your votes are welcome! :-) My personal favourite is 3, obviously. Overloading is different from overriding. And it only gets worse, because we do have To reply to @bstaletic:
Yes. As far as I know, just one (
Yes. Though gently doing so, because I created deprecated aliases? Users' code should break. They should just get deprecation warnings.
Agreed. Planning on adding a big note in the docs :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your votes are welcome! :-)
My vote goes to whatever is least disruptive for users. I guess that makes it easy for me to vote against option 2. 1 and 3 seem to be about the same in this regard.
Moving functions from
pybind11
topybind11::detail
namespace.
Yes. As far as I know, just one (
get_type_overload
/detail::get_type_override
), right?)
Right.
undocumented, taking a parameter with a type in the detail namespace (detail::type_info), dealing with the internals/being an auxiliary function to a public-facing templated interface (get_overload/get_override),
I wouldn't be surprised if Hyrum's law rears its ugly head.
and I have created a deprecated alias outside of
detail
.
Oh, I didn't catch that! Nice.
If necessary, I can move it back out of
detail
. It just seemed like an oversight.
It does seem like an oversight. I guess we can move it into detail
.
Renaming things.
Yes. Though gently doing so, because I created deprecated aliases? Users' code should break. They should just get deprecation warnings.
-Werror
would promote the deprecation warning into an error, though I guess that's fine, because it's precisely what the user asked for.
do { \ | ||
PYBIND11_OVERRIDE_IMPL(PYBIND11_TYPE(ret_type), PYBIND11_TYPE(cname), name, __VA_ARGS__); \ | ||
return cname::fn(__VA_ARGS__); \ | ||
} while (false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of users using PYBIND11_OVERLOAD
without a trailing semicolon. However, that's OVERLOAD
, the deprecated macro. Moving on.
You forgot to update the |
Alright, I'm waiting for #2370 before adding to the changelog and upgrade guide to avoid merge conflicts, but I believe this is ready for review! To reiterate:
|
f2100d9
to
fc1c57f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My honest opinion: it is disproportionally disruptive to rename the macros, just to be semantically more correct. If we add a footnote to the documentation, explaining that override would be a more fitting name, but for historical reasons overload stuck, we're good.
My recommendation is to simply remove the semicolon at the end of the PYBIND11_OVERLOAD_PURE_NAME macro (as suggested under #2166) and mention it in the release notes. It's very easy to adjust to, therefore I think it's fine doing this in a patch release.
Yes, true, but then following that reasoning, such a mistake can never get fixed?
But yes, this is fine with me as well, to just cherry-pick the first commit. Though @bstaletic was arguing that that would be more "breaking" than the deprecating PR... |
https://github.com/search?q=PYBIND11_OVERLOAD
I believe that'll trickle through the code bases much faster and decrease confusion monotonically, because the macros will be consistent. |
Alright, good point! Maybe we can provide a quick search-and-replace script to the upgrade guide. At any rate, yes, the work is done, so now it's choosing an option. Probably up to @wjakob to decide, but let's see if we get more votes! |
I took another look. I really don't mind the name change, especially given that the previous naming scheme was arguably confusing/incorrect. It's also a good opportunity to clean up the inconsistency regarding semicolon usage. What I don't like:
|
Right, I'll have another look with that feedback in mind! :-) |
….. } while (false), and resolve trailing semicolon
…VERRIDE_* and get_override
…plementation and internals
…d add warning about deprecated aliases
fc1c57f
to
543d5a4
Compare
(not sure why, but GitHub doesn't allow me to click the "re-request review" for you, @virtuald. But if you're interested, please do have a look :-) ) |
Changing the names seems like a reasonable compromise to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great now, approved by me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me.
Thanks all! Let's see how users react, on whether we need to update our upgrade guide further, or not :-) |
`PYBIND11_OVERRIDE_IMPL` is an implementation detail and not meant to be used outside the pybind11 source tree. Notes: * For easy reference: `PYBIND11_OVERRIDE_IMPL` was added to python_games.cc in cl/379240506. * Discovered in connection with google/pybind11clif#30015, which changes `PYBIND11_OVERRIDE_IMPL`. (The pywrapcc fork of pybind11 is not currently used in production, but we're using it regularly to run TAP Global Presubmits, to test go/pyclif_pybind11_fusion developments.) * FYI: Test coverage seems to be incomplete: control flow passes through the changed code for many tests, but replacing `"mean_field_population"` with `"XXXmean_field_population"` does not break any tests (see isolated TGP results under http://tap/OCL:517999370:BASE:517998831:1679332509158:a5f7412a). I.e. a test with a Python override is missing. * FYI: The `PYBIND11_OVERLOAD_*` macros used in other parts of python_games.cc are deprecated since Sep 2020 (pybind/pybind11#2325). It is recommended to replace them with the equivalent `PYBIND11_OVERRIDE_*` macros. PiperOrigin-RevId: 518266312 Change-Id: Ica90764a71b8ed7795b2f26ab02a904bf2ad901e
Closes #2166