Skip to content

Fix a clang warning [-Wshadow-field-in-constructor-modified] #2780

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.

Sign up for GitHub

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

Merged
henryiii merged 2 commits into from
Jan 14, 2021
Merged

Fix a clang warning [-Wshadow-field-in-constructor-modified] #2780

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d8b7335
Fix a clang warning from [-Wshadow-field-in-constructor-modified]
asmaloney Jan 9, 2021
c0028ed
Change name based on review
asmaloney Jan 9, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion include/pybind11/pybind11.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1910,7 +1910,7 @@ template <return_value_policy Policy = return_value_policy::reference_internal,
template <typename InputType, typename OutputType> void implicitly_convertible() {
struct set_flag {
bool &flag;
set_flag(bool &flag) : flag(flag) { flag = true; }
set_flag(bool &my_flag) : flag(my_flag) { my_flag = true; }
Copy link
Collaborator

@YannickJadoul YannickJadoul Jan 9, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my_flag sounds very tutorial-for-programming-like, though. Could you change this to flag_ or f or so (or suggest something else)?

Also (mostly to other reviewers): should we turn on more warning flags in CI? What's our goal when it comes to such warnings?

Copy link
Contributor Author

@asmaloney asmaloney Jan 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured you would have a preferred naming for something like this, I just couldn't find it. I use m for member style (mFlag) so I never have to deal with this in my own code.

I'll use flag_.

Copy link
Collaborator

@YannickJadoul YannickJadoul Jan 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I can't really find it either. We do use m_flag for private class members, but this is a struct, so flag is part of the interface (well, it's a local struct in a function, so it's not that important, but you don't want to write some_struct.m_flag, I think :-) )

Copy link
Collaborator

@YannickJadoul YannickJadoul Jan 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A quick look seems that f and flag_ would be the two options. I found instances of both conventions. I think this is fine, though, so thanks!

~set_flag() { flag = false; }
};
auto implicit_caster = [](PyObject *obj, PyTypeObject *type) -> PyObject * {
Expand Down