Generate bitfield accessor names eagerly#1058
Conversation
fitzgen
left a comment
There was a problem hiding this comment.
Looks good, but I have a few questions below and a couple nitpicks that I'd like to see addressed before we merge this.
Thanks!
|
|
||
| /// Name of the generated Rust setter for this bitfield. | ||
| pub fn setter_name(&self) -> &str { | ||
| self.setter_name.as_ref().unwrap() |
There was a problem hiding this comment.
Let's replace these unwraps with expects that detail the invariant that is being broken if this panics:
self.setter_name
.as_ref()
.expect("`Bitfield::setter_name` should only be called after assigning field names")And the same for getter_name.
| } | ||
|
|
||
| fn deanonymize_fields(&mut self) { | ||
| fn deanonymize_fields(&mut self, ctx: &BindgenContext, methods: &[Method]) { |
There was a problem hiding this comment.
Maybe assign_field_names is a slightly better name for this method now? I'm not married to either name...
|
|
||
| fn deanonymize_fields(&mut self) { | ||
| fn deanonymize_fields(&mut self, ctx: &BindgenContext, methods: &[Method]) { | ||
| use std::collections::HashMap; |
There was a problem hiding this comment.
Any particular reason that this isn't at the top level? If not, let's put it there.
| /// | ||
| /// Panics if there is no item for the given `FunctionId` or if the resolved | ||
| /// item is not a `Function`. | ||
| pub fn resolve_func(&self, func_id: FunctionId) -> &Function { |
| .unwrap() | ||
| .deanonymize_fields(self); | ||
|
|
||
| self.items.insert(id, item); |
There was a problem hiding this comment.
Why do we have to remove the item and then put it back again? Why doesn't the previous approach work anymore?
This results in two passes over the items, while the previous approach was a single pass because there was no collect call on the iterator, just the for loop.
I doubt it is a ton of overhead, and the code isn't so difficult to follow that I'm worried about code paths where we forget to return the item into the set, but I guess I'm just a little confused and it seems like the old approach was simpler.
There was a problem hiding this comment.
Yeah, old approach was definitely simpler! I chose this approach because Context was not needed, but now it is. And because of this borrow checker become sad (because we are borrowing self.items). I tried to temporary mem::replace whole self.items but it didn't work out, because we actually need items array (see call to resolve_function in has_method).
So I decided to go approach like in compute_bitfield_units.
I thought that I should factor out this pattern out, but I completely forgot about it 😳
|
☔ The latest upstream changes (presumably #1059) made this pull request unmergeable. Please resolve the merge conflicts. |
Also clean a bit.
b708e07 to
8db2d66
Compare
8db2d66 to
9827ad5
Compare
Also make impl_partialeq test to also cover impl_debug case.
9827ad5 to
3ff8dba
Compare
fitzgen
left a comment
There was a problem hiding this comment.
👍
Couple nitpicks -- sorry if I missed them in an earlier revision! Will r+ ASAP when they're addressed!
|
|
||
| /// Get the name of this bitfield. | ||
| fn name(&self) -> Option<&str> { | ||
| self.data.name() |
There was a problem hiding this comment.
This is identical to <Bitfield as FieldMethods>::name right above -- I don't think it is needed. Am I missing something?
| /// Name of the generated Rust setter for this bitfield. | ||
| /// | ||
| /// Panics if called before assigning bitfield accessor names or if | ||
| /// this bitfield have no name. |
| /// | ||
| /// Panics if attempt to resolve given `ItemId` inside the given | ||
| /// closure is made. | ||
| fn with_loaned_item<F: FnOnce(&BindgenContext, &mut Item)>( |
There was a problem hiding this comment.
For legibility, let's move the FnOnce bound to a where clause. Additionally, we should allow the function to return things.
fn with_loaned_item<F, T>(&mut self, id: ItemId, f: F) -> T
where
F: FnOnce(&BindgenContext, &mut Item) -> T
{
...
}There was a problem hiding this comment.
Yeah, I agree, it is more legible. But rustfmt thinks otherwise.
Is rustfmt used to move bounds into where in the past?
Additionally, we should allow the function to return things.
Good point!
| .collect(); | ||
|
|
||
| for id in comp_item_ids { | ||
| self.with_loaned_item(id, |ctx, item| { |
There was a problem hiding this comment.
This API is pretty nice to use :)
3ff8dba to
91796cf
Compare
|
@bors-servo r+ |
|
📌 Commit 91796cf has been approved by |
Generate bitfield accessor names eagerly @fitzgen r? I'm not sure about `deanonymize_fields`, as we now assign names to data members and also generate names for the bitfield accessors, but can't come up with a better name.
|
☀️ Test successful - status-travis |
I've added a `ParseCallbacks` method called `field_name` which is given the same `FieldInfo` struct that `field_visibility` takes. I wasn't entirely sure where to change field names, I ended up doing it in what was `deanonymize_fields` which has been renamed to `assign_field_names` as suggested by [this comment](rust-lang#1058 (comment)) Related to rust-lang#1097 and rust-lang#1098
I've added a `ParseCallbacks` method called `field_name` which is given the same `FieldInfo` struct that `field_visibility` takes. I wasn't entirely sure where to change field names, I ended up doing it in what was `deanonymize_fields` which has been renamed to `assign_field_names` as suggested by [this comment](rust-lang#1058 (comment)) Related to rust-lang#1097 and rust-lang#1098
I've added a `ParseCallbacks` method called `field_name` which is given the same `FieldInfo` struct that `field_visibility` takes. I wasn't entirely sure where to change field names, I ended up doing it in what was `deanonymize_fields` which has been renamed to `assign_field_names` as suggested by [this comment](rust-lang#1058 (comment)) Related to rust-lang#1097 and rust-lang#1098
@fitzgen r?
I'm not sure about
deanonymize_fields, as we now assign names to data members and also generate names for the bitfield accessors, but can't come up with a better name.